From jat@google.com Tue Mar 1 00:26:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E0A3A6A97 for ; Tue, 1 Mar 2011 00:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.735 X-Spam-Level: X-Spam-Status: No, score=-105.735 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER2tFpf7N0qM for ; Tue, 1 Mar 2011 00:26:38 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id B3FD23A69C2 for ; Tue, 1 Mar 2011 00:26:37 -0800 (PST) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p218Rcib001496 for ; Tue, 1 Mar 2011 00:27:38 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298968059; bh=u4YBnoi4I4PpBdo0JDa679P9Rg4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ocqThFk/JYyG42bNGr23BhuVvzU9uW4KqJvEQJJd58lZ03PQ5tG46eJuLKJ9Vgj6g klP4JrSOOTjmhWRVjIWeQ== Received: from gwj20 (gwj20.prod.google.com [10.200.10.20]) by wpaz33.hot.corp.google.com with ESMTP id p218RXA6026832 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 1 Mar 2011 00:27:37 -0800 Received: by gwj20 with SMTP id 20so2631255gwj.5 for ; Tue, 01 Mar 2011 00:27:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=5N/5+YlnICCUxdKCXj98djxqGr8c6ipMIvOtYf0KkQk=; b=xrdjTUHYqzlsKXjYEP348ltrSACpTROUorkuTOh7d2erk4lqkAMOpkqnw1O3qmg0ZK zcpNGBBciWhKpDbj5wwA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=BSSkkg394eGuGWWZ4/NF3DN1riAfjCCLEC+ArEuA9zr/cNikBZIauLKfqzr8xQ0ugM SVpIpSzbinjL3WtOqh3Q== Received: by 10.150.198.11 with SMTP id v11mr8443734ybf.388.1298968057107; Tue, 01 Mar 2011 00:27:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Tue, 1 Mar 2011 00:27:17 -0800 (PST) In-Reply-To: <4D6CA34A.3050301@warmcat.com> References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <4D6C9F6D.1030306@warmcat.com> <4D6CA34A.3050301@warmcat.com> From: John Tamplin Date: Tue, 1 Mar 2011 03:27:17 -0500 Message-ID: To: Andy Green Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 08:26:39 -0000 On Tue, Mar 1, 2011 at 2:42 AM, Andy Green wrote: > Well, I feel your pain, but it's notable nothing has been suggested to ne= ed > that extension area per-packet and it's legitimate to ask for an example = of > what would need it and if we can get rid of it. =C2=A0I'm not asking out = of the > blue it is part of looking at moving masking down the packet and make sur= e > it can't run on into the undefined extension area in a controllable way. > > If there are reasonable examples I am happy to accept that and forget abo= ut > it. >From memory, a couple of things were discussed that would need to send extension data: - MIME types or other metadata for content - A more advanced compression algorithm might want to send a compression dictionary, or identify separate streams with separate compression state --=20 John A. Tamplin Software Engineer (GWT), Google From andy.warmcat.com@googlemail.com Tue Mar 1 00:46:37 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C23C3A6969 for ; Tue, 1 Mar 2011 00:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SHGS756kozU for ; Tue, 1 Mar 2011 00:46:36 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 401133A6ABC for ; Tue, 1 Mar 2011 00:46:35 -0800 (PST) Received: by wwb22 with SMTP id 22so3120607wwb.13 for ; Tue, 01 Mar 2011 00:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yKQQ3UYsYEy7xbScFgs6IuQiiXhbGY9Vduc9nLBM9+8=; b=HX/QJKTk3MrEgj4TeYxTd/F8k7uBbCLTe8tVGuSnFv/uQzbX2wfKbp0zLaoB5XctoM Bc1yf/ZC/Z6wdZk7Mgmt0G8c1aKE8cqP96A91wxdjOLhHMG2l7dpcHTyg0U9hOCCz1Is k87KbMr71Dh5rg0sQfrXKwdIsvHJu9X6xnDRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=l23DNCvReyWEMv42ka/Zuyl4jxK7allqURUCEzBKNuz4uAQsC0zImZOuoxs/L8/1Sc zVq531o6O0RAhaOpJ1l1NrpWXtNon6kWAQEBTALHxpUOXigqwnJh75hXmLT222GCb/Ip OCLbMh5hjcXlOjSr5f1rp5UZ/oVlQ/RF21UbI= Received: by 10.227.144.131 with SMTP id z3mr5951830wbu.198.1298969257984; Tue, 01 Mar 2011 00:47:37 -0800 (PST) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id bd8sm281215wbb.19.2011.03.01.00.47.36 (version=SSLv3 cipher=OTHER); Tue, 01 Mar 2011 00:47:37 -0800 (PST) Sender: Andy Green Message-ID: <4D6CB2A8.7010707@warmcat.com> Date: Tue, 01 Mar 2011 08:47:36 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Tamplin References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <4D6C9F6D.1030306@warmcat.com> <4D6CA34A.3050301@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 08:46:37 -0000 On 03/01/2011 08:27 AM, Somebody in the thread at some point said: > On Tue, Mar 1, 2011 at 2:42 AM, Andy Green wrote: >> Well, I feel your pain, but it's notable nothing has been suggested to need >> that extension area per-packet and it's legitimate to ask for an example of >> what would need it and if we can get rid of it. I'm not asking out of the >> blue it is part of looking at moving masking down the packet and make sure >> it can't run on into the undefined extension area in a controllable way. >> >> If there are reasonable examples I am happy to accept that and forget about >> it. > > From memory, a couple of things were discussed that would need to send > extension data: > - MIME types or other metadata for content > - A more advanced compression algorithm might want to send a compression > dictionary, or identify separate streams with separate compression state Thanks. Extensions sending extension data generally I could already imagine as being needed. But as it stands, the extension data is coupled to a specific packet + payload, right inside it. Both those examples seem like they could work fine outside of that, using extended opcodes already allowed for and bound to a stream, the default stream or a specific muxed stream. Whatever the extension data is that binds itself to a stream using the current scheme, it has to be generated synchronous to the stream payload content since its content goes into a payload packet. So it would always be possible to generate the same content in a reliable way in a separate frame before the payload content it wanted to impact. It'd leave the existing spec a lot cleaner that way to break extension data out into its own frame with reserved, extended opcodes and extension data as normal payload, rather than have this really not specified extension data area of unknown length inside every frame. -Andy From w@1wt.eu Tue Mar 1 00:47:43 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3E4C3A6ABD for ; Tue, 1 Mar 2011 00:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCPMMFsK3tmD for ; Tue, 1 Mar 2011 00:47:43 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id BB1AD3A69FA for ; Tue, 1 Mar 2011 00:47:42 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p218mhNC011862; Tue, 1 Mar 2011 09:48:43 +0100 Date: Tue, 1 Mar 2011 09:48:43 +0100 From: Willy Tarreau To: Andy Green Message-ID: <20110301084843.GB11767@1wt.eu> References: <20110301060349.GC9463@1wt.eu> <4D6CA0A6.7000401@warmcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D6CA0A6.7000401@warmcat.com> User-Agent: Mutt/1.4.2.3i Cc: Hybi , Gabriel Montenegro , Greg Wilkins Subject: Re: [hybi] Hello / idle timeout X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 08:47:43 -0000 On Tue, Mar 01, 2011 at 07:30:46AM +0000, Andy Green wrote: > On 03/01/2011 06:15 AM, Somebody in the thread at some point said: > >On 1 March 2011 17:03, Willy Tarreau wrote: > >>BTW I'd prefer to see a suggested heartbeat interval than a > >>timeout, > > > >work for me. > > Isn't it better to think of this as "idle timeout" for the channel? If > there's normal traffic coming from the other guy at any time, actually > the receiver can take that as a PONG for a PING he didn't have to send > and reset his idle timeout. It's only after the channel is idle for the > idle timeout he has to think about making synthetic traffic via PING to > confirm all is still well. Yes, I agree this is an idle timeout. I thought it was obvious but in fact it was not, given that not all components behave the same. Regards, Willy From jat@google.com Tue Mar 1 00:56:31 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1973A6A91 for ; Tue, 1 Mar 2011 00:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.921 X-Spam-Level: X-Spam-Status: No, score=-105.921 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOONKUlVXF02 for ; Tue, 1 Mar 2011 00:56:30 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 13D553A69FA for ; Tue, 1 Mar 2011 00:56:29 -0800 (PST) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p218vV64010042 for ; Tue, 1 Mar 2011 00:57:32 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298969852; bh=opEJAq5NYha4cGaOdRxIMonMP2c=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=pf8vIQSFERfDz8jG2WpOrLBB0QG/nF57asR/wp11w36TPwH/OA5EwTOZihPIlnZy9 2tfKVFGPy0PZHMig+MDng== Received: from ywg8 (ywg8.prod.google.com [10.192.7.8]) by hpaq11.eem.corp.google.com with ESMTP id p218vTtg016924 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 1 Mar 2011 00:57:30 -0800 Received: by ywg8 with SMTP id 8so1901784ywg.34 for ; Tue, 01 Mar 2011 00:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=sx/y+Ma+KDRvaG/Vf2vHEV3PYsSAkOJHIKiIPLvIBsg=; b=YqabWlDDpWbwxn3+9TTnrH+DwQm/R21hYVCw5VkQPaD3EmiydhG3wsoRKUBioiv+1w yTzLq798pawspQt21Ksw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ltOyLXRLaSDzzg7pBT8dMDnG6aFwWQzRae8r3OQLq6RgEQAWukZ1c9Uaw7mKGaeXbL yO5KK3jZHgpO21YyE1cw== Received: by 10.150.198.11 with SMTP id v11mr8476887ybf.388.1298969849148; Tue, 01 Mar 2011 00:57:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Tue, 1 Mar 2011 00:57:09 -0800 (PST) In-Reply-To: <4D6CB2A8.7010707@warmcat.com> References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <4D6C9F6D.1030306@warmcat.com> <4D6CA34A.3050301@warmcat.com> <4D6CB2A8.7010707@warmcat.com> From: John Tamplin Date: Tue, 1 Mar 2011 03:57:09 -0500 Message-ID: To: Andy Green Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 08:56:31 -0000 On Tue, Mar 1, 2011 at 3:47 AM, Andy Green wrote: > Both those examples seem like they could work fine outside of that, using > extended opcodes already allowed for and bound to a stream, the default > stream or a specific muxed stream. > > Whatever the extension data is that binds itself to a stream using the > current scheme, it has to be generated synchronous to the stream payload > content since its content goes into a payload packet. =C2=A0So it would a= lways be > possible to generate the same content in a reliable way in a separate fra= me > before the payload content it wanted to impact. > > It'd leave the existing spec a lot cleaner that way to break extension da= ta > out into its own frame with reserved, extended opcodes and extension data= as > normal payload, rather than have this really not specified extension data > area of unknown length inside every frame. Right, but what got us to where we are is that we could not agree on whether using new opcodes (and nesting them) or having separate extension data was the better approach, and within that we couldn't get the details of either of them agreed on. So, we wound up with what we have, which can be used to implement any of those proposed extension mechanisms. Maybe things are different from last summer, but I do not know why to expect we can define the extension format now when we couldn't then. As one example, if you use the nested opcode approach, you absolutely can't interpret anything in the payload past an extension you don't understand. At least with a separate extension area, if we came up with a tag/value approach you could imagine being able to skip extension data that you didn't understand. So, I tend to think of extension by opcode as mandatory extensions, and extension by metadata as optional ones, but that is just me and another thing we never could agree on. I urge you to read the endless discussions last summer where exactly these options were discussed before suggesting them. Also, I do not think it is necessary to define it in the base spec, since a future revision could define that there is no extension data and allocate adjacent reserved bits to the opcode field for extension opcodes, and no implementation of the current spec would be broken by that change. --=20 John A. Tamplin Software Engineer (GWT), Google From andy.warmcat.com@googlemail.com Tue Mar 1 01:16:18 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8793A6AE3 for ; Tue, 1 Mar 2011 01:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t99B6m6C+OhO for ; Tue, 1 Mar 2011 01:16:18 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id B16933A6ADC for ; Tue, 1 Mar 2011 01:16:17 -0800 (PST) Received: by eye13 with SMTP id 13so1892463eye.31 for ; Tue, 01 Mar 2011 01:17:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ctgckPXEjtM+GGfYQxGZfJpq3xdDE/25cB2iyNBkBBw=; b=QXAGdkKhbDvxqg3mvkI+lVI6YvbFitQT0V8bnCkBxKxN5IjzrypOnX5KzoekjYAvlI phQOuhT4M+q2uDBoouSJt8KblAOTgtCnoaEuj3GJ0KQvl+W3Jhs1j+chdkIMT2sp8188 44/x562quOAzWHjmhxAKEo+EUY3k6bMDhpOXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Yue5Dsjm9Iq072+lnww04ee0m1UByGzogDZ//uzvalV6fxpFwHXSxoo9Wvz5mgK0Oe phxOPFXIF80xIhlbThXKa2/xS7YbHyHbwJCnMVjC0Zhf1zzG4GH3zCgvs8E43N9kPEa5 ci0MqkwlFtwNLrH7cMoF+tfD7FAHB+CgXgdiw= Received: by 10.213.10.207 with SMTP id q15mr5009743ebq.90.1298971039386; Tue, 01 Mar 2011 01:17:19 -0800 (PST) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id t5sm3993226eeh.14.2011.03.01.01.17.18 (version=SSLv3 cipher=OTHER); Tue, 01 Mar 2011 01:17:18 -0800 (PST) Sender: Andy Green Message-ID: <4D6CB99D.8010801@warmcat.com> Date: Tue, 01 Mar 2011 09:17:17 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Tamplin References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <4D6C9F6D.1030306@warmcat.com> <4D6CA34A.3050301@warmcat.com> <4D6CB2A8.7010707@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 09:16:19 -0000 On 03/01/2011 08:57 AM, Somebody in the thread at some point said: Hi - > As one example, if you use the nested opcode approach, you absolutely Sorry I am not talking about any nesting but sequential normal frames. For example: [BINARY_OPCODE hdr + len][payload] [EXTENDED_OPCODE hdr + len][payload (it is extension data, eg, compression dictionary)] [BINARY OPCODE hdr + len][payload] ... there is no problem with following the stream even if I don't understand the extension, since it's a normal frame with length and payload defined just a funny opcode. > I urge you to read the endless discussions last summer where exactly > these options were discussed before suggesting them. I am urged to read endless discussion... ^^ > Also, I do not think it is necessary to define it in the base spec, > since a future revision could define that there is no extension data > and allocate adjacent reserved bits to the opcode field for extension > opcodes, and no implementation of the current spec would be broken by > that change. Except the uncertainty of having zero or more undefined bytes in the middle of every packet raises issues about moving masking key past it, and parsing the frame with snoopers, it's also kind of strange to see such an area with at least no defined length control over it in a protocol. Anyway thanks for engaging with my question: I made my suggestions if it doesn't sounds interesting to anyone else I'll let it lie. -Andy From toni.ruottu@gmail.com Tue Mar 1 04:34:16 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE613A67AD for ; Tue, 1 Mar 2011 04:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMlSKGR3sSBs for ; Tue, 1 Mar 2011 04:34:15 -0800 (PST) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by core3.amsl.com (Postfix) with ESMTP id B02D63A67E3 for ; Tue, 1 Mar 2011 04:34:15 -0800 (PST) Received: by gwj22 with SMTP id 22so2604509gwj.27 for ; Tue, 01 Mar 2011 04:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=uJJyjG1qOU4dK/pLDZNj9AXI7JGnPq0IXQsT8LRyctA=; b=d7EjtOa5w1vpNEBYw/earuSGP2pWauCDify1fEqDXtO0GUTiYW/7JVv3n5fuVc5QmG AKh9xM1/qeyG0fmFd8mSjKwlJ293Boj1um0SY3DTwwBJmQ6FPBMa3/9qjkCZaRWa9Web W0oJmto0uOmRD9OqJUFnZPwhei8XtHxjOlFHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=GzMAjsWX2H9RkDav7L/EBcWAlxlxyO0BZj38Kq9V4FaaOvbzpLknMMDmzy87oDL+Nh /R+WTGNQFNJRwsLdszr8ddMT5rKNiZ97FZ9+x/xezVJcRed11y1MXPztWIkfm7k344yT gMXWgQ7TYB9wlvcoJhq6IGIJd+Qt+NTYU1MBg= MIME-Version: 1.0 Received: by 10.151.63.24 with SMTP id q24mr8674106ybk.385.1298982917846; Tue, 01 Mar 2011 04:35:17 -0800 (PST) Sender: toni.ruottu@gmail.com Received: by 10.147.167.9 with HTTP; Tue, 1 Mar 2011 04:35:17 -0800 (PST) Date: Tue, 1 Mar 2011 14:35:17 +0200 X-Google-Sender-Auth: okJvgC5yYSSVRZILQ5oe_h91Gsk Message-ID: From: Toni Ruottu To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] Serverside Sec-headers X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 12:34:16 -0000 hello Why do WebSockets have Sec- headers on the server-side? I think all headers should be accessible to the server even when it is untrusted and running in a sandbox. I see no reason why any of the headers should be hidden. The untrusted server side code should probably also have access to Sec- headers, but maybe using Sec- prefix with the server side headers is till sending the wrong message out to implementors. It does make sense for the platform to verify that the incoming connection is a WebSocket connection before handing it over to untrusted code. The platform should also decide the resource and port that the untrusted server is allowed to use. This is the model we have been using in our BrowserSocket experiments. See http://browsersocket.org/ for details. --Toni From Simo.Veikkolainen@nokia.com Tue Mar 1 04:49:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68E583A67F9 for ; Tue, 1 Mar 2011 04:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6BNcXX54-gk for ; Tue, 1 Mar 2011 04:49:12 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 753F43A67C0 for ; Tue, 1 Mar 2011 04:49:12 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p21CnNk8017908; Tue, 1 Mar 2011 14:49:37 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 14:49:26 +0200 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 1 Mar 2011 13:49:26 +0100 Received: from 008-AM1MPN1-002.mgdnok.nokia.com ([169.254.2.164]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0270.002; Tue, 1 Mar 2011 13:49:25 +0100 From: To: , Thread-Topic: [hybi] Hello frames? Thread-Index: AQHL144TzEmbNhe9s0+0y2qPkkKHD5QXe7uAgAAkEwCAAE0vgIAAA14AgAB3ORA= Date: Tue, 1 Mar 2011 12:49:25 +0000 Message-ID: References: <20110301060349.GC9463@1wt.eu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.34.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Mar 2011 12:49:26.0897 (UTC) FILETIME=[19316E10:01CBD80F] X-Nokia-AV: Clean Cc: hybi@ietf.org, Gabriel.Montenegro@microsoft.com Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 12:49:13 -0000 > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of > ext Greg Wilkins > Sent: 01 March, 2011 08:16 > To: Willy Tarreau > Cc: Hybi; Gabriel Montenegro > Subject: Re: [hybi] Hello frames? >=20 > On 1 March 2011 17:03, Willy Tarreau wrote: > > BTW I'd prefer to see a suggested heartbeat interval than a > > timeout, >=20 > work for me. Hi, I haven't participated in the discussion before, but the issue of heart= beat is so close to my heart it merits a few comments: Being able to suggest a heartbeat interval is indeed very valuable for mobi= le devices. How the negotiation actually takes place, and which value gets = chosen is a more complex issue. I'm hoping the websocket client on a mobile= device would have priority in setting the value since it might know someth= ing about the access network characteristics in order to select an optimal = (=3Dlong) interval. But I understand the server side is keen on getting rid= of dead connections sooner than later, preferring perhaps a shorter heartb= eat. But, for now I think it is enough to have a placeholder in the protoco= l where the proposed interval values can be exchanged. Being able to use a single heartbeat for multiple websocket connections mig= ht also be beneficial, but not that critical. In cellular networks, waking = up the radio frequently is clearly worse than sending out some more bytes o= nce the radio is on. Clever operating systems might also offer an API for q= ueuing multiple heartbeat messages and sending them out at one go. > > I'm even thinking that if we want to announce that, we'd better do > that > > in the initial HTTP handshake as a header, >=20 > Also fine with that Is there any difference in practice in having the interval in the HTTP hand= shake or in a websocket message? In terms of interworking with legacy proxi= es and other middleboxes there might be? I guess not? Regards, Simo > > That also means that it'd leave the ping usable for any purpose we > > want :-) >=20 > for a hello frame for example. >=20 > cheers > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From andy.warmcat.com@googlemail.com Tue Mar 1 04:58:19 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1684D3A67DF for ; Tue, 1 Mar 2011 04:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSKM8xP+b560 for ; Tue, 1 Mar 2011 04:58:18 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id CD5483A67B6 for ; Tue, 1 Mar 2011 04:58:17 -0800 (PST) Received: by eye13 with SMTP id 13so1961301eye.31 for ; Tue, 01 Mar 2011 04:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vL1x1QjXjfrH2CUa5D0vzMJFyvBxqTodKnf1Ulqy13A=; b=h9of+dCwyhLmC80p21bf7WO8pfGxXDBevm/nFAaJeit+4Rc+0Z0f1ipQ3SlY2dLVXz Mu41VfwyqrWENaXYcGW0miiUGELmrMdinCtnUp/KZukHAGeFOPyXq/Jinzs+Zq6BAExY LSHnd5/sDDx1CtEL6SaDf6029fAZV0X5NgSrk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=g9fYH1Ff8QZEva9k1Xr9k+z10W3rnEyVVcRMLOXJFREHbOKm5Vsy46szfChaaVhEIT RQiWBAnSo/cxKTFJVS1YbZ6F4/isqBV3wvjBWGJZyhTX9g8h6jCE/J49JHdImmk4bIVB T5raCIniH+aniP+t/4ZJ6bpovOi5wlLe7hCpg= Received: by 10.213.103.130 with SMTP id k2mr3142428ebo.87.1298984360063; Tue, 01 Mar 2011 04:59:20 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id t5sm4178469eeh.8.2011.03.01.04.59.18 (version=SSLv3 cipher=OTHER); Tue, 01 Mar 2011 04:59:19 -0800 (PST) Sender: Andy Green Message-ID: <4D6CEDA5.1060306@warmcat.com> Date: Tue, 01 Mar 2011 12:59:17 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: <20110301060349.GC9463@1wt.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, Gabriel.Montenegro@microsoft.com, gregw@intalio.com Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 12:58:19 -0000 On 03/01/2011 12:49 PM, Somebody in the thread at some point said: Hi - >>> I'm even thinking that if we want to announce that, we'd better >>> do >> that >>> in the initial HTTP handshake as a header, >> >> Also fine with that > > Is there any difference in practice in having the interval in the > HTTP handshake or in a websocket message? In terms of interworking > with legacy proxies and other middleboxes there might be? I guess > not? In practical terms it's probably easier and simpler to define and sell people on the idea that there's another optional header that can be sent out at the same time as the client and server handshake headers. Otherwise you'd have to use one of the scarce reserved opcodes for setting this kind of thing or overload PING in an ugly way, etc. Plus the idle limit is really for the entire connection like the initial headers are. -Andy From mcmanus@ducksong.com Tue Mar 1 06:37:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4443A67B2 for ; Tue, 1 Mar 2011 06:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VokkvtKNlmKW for ; Tue, 1 Mar 2011 06:37:12 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 10A333A67A8 for ; Tue, 1 Mar 2011 06:37:11 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id 992BD10442; Tue, 1 Mar 2011 09:38:14 -0500 (EST) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 1B23E101F6; Tue, 1 Mar 2011 09:38:10 -0500 (EST) From: "Pat McManus @Mozilla" To: Greg Wilkins In-Reply-To: References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Mar 2011 09:37:47 -0500 Message-ID: <1298990267.2498.668.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 14:37:13 -0000 On Tue, 2011-03-01 at 15:42 +1100, Greg Wilkins wrote: > However, I do not think > they have well communicated the technical case against it. * The mask increases the security properties of the protocol by making it safe for transmission across transparent http proxies with certain classes of bugs. This is true for both server (i.e. attacker) provided data as well more generally true other data sources that should be masked for transport across legacy http. The hybi archives might qualify as such a data source. * The mask is incredibly cheap to implement. You can do XOR at the rate of your memory bandwidth. The benefit to "optimizing it away" is at best marginal even in high bandwidth scenarios. * transparent and silent proxies are infrastructure elements and their presence are not always known to clients at extension negotiation time. Even clients such as websocket intermediaries may not be aware of them, or they may come and go as routing schemes change. --> consistent application of masking makes websockets a generally more robust protocol at an insignificant cost. Creating a path for the defense to be disabled is penny wise pound foolish. From mcmanus@ducksong.com Tue Mar 1 06:39:35 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C993A67B8 for ; Tue, 1 Mar 2011 06:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuiKmMmtXFVl for ; Tue, 1 Mar 2011 06:39:30 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id C3B083A67B3 for ; Tue, 1 Mar 2011 06:39:30 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id F016210442; Tue, 1 Mar 2011 09:40:33 -0500 (EST) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 741FB101F6; Tue, 1 Mar 2011 09:40:29 -0500 (EST) From: "Pat McManus @Mozilla" To: Andy Green In-Reply-To: <4D6CA212.40204@warmcat.com> References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <33B46028-223B-48C6-AA17-88FBE046E064@gmail.com> <4D6CA212.40204@warmcat.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Mar 2011 09:40:07 -0500 Message-ID: <1298990407.2498.671.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: Greg, Hybi , Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 14:39:35 -0000 On Tue, 2011-03-01 at 07:36 +0000, Andy Green wrote: > Don't forget a packet snooper is screwed by the mask already in current > draft, it doesn't know if the packet is client -> server and has a > 4-byte mask prepended, or server -> client and lacks it. Being transported on a stream based protocol, it is screwed whenever it misses the handshake as it cannot be sure where the frame starts even in the total absence of an asymmetric mask. If it has the handshake, then there is no problem, if it misses it then it has to apply a pile of heuristics - which still seems quite doable with masking (i.e. port numbers, testing likely bytes for known opcodes, testing them with the mask, etc..). -- http://www.getfirefox.com/ From andy.warmcat.com@googlemail.com Tue Mar 1 06:57:27 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D663A6818 for ; Tue, 1 Mar 2011 06:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLxRdAkOQ9GH for ; Tue, 1 Mar 2011 06:57:26 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 035D33A6830 for ; Tue, 1 Mar 2011 06:57:25 -0800 (PST) Received: by ewy9 with SMTP id 9so2026089ewy.31 for ; Tue, 01 Mar 2011 06:58:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cHe2kzjtkSX3rHbojeCRzyX8WRohvNKZkTds51TssPM=; b=i5CTbAYVeSTp6wwe4R8jrrhYM/jF4vBCzoMm9IUlm7rFScg21WstqzLWEmFkDqTvof jcVosXBV/cygcVhSncVe/PLCzwhVVqBwG0saFDRgUubv0U6DBRtAXz6L2utxEE0ZayHS nZJp5xoO6eGlG9gkrODOQwb8ygYxY1uBx0l+w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=v97f+pLd4OPBhe7pP9uiwPUDUeDQ8zqv6Y61y3EAxw9ZYgLX02d2i2uBWH0aivAPKv HOlOKT/2ByaXYj5ZVIJjQzlVX/zGEd8j3OdI3My3RlZ2Vrb+I90+nQGtIl5KMHU3nhU9 c/eJuKMBz7DPuwENajq3kdkbi4APYUMcsXHGY= Received: by 10.213.25.143 with SMTP id z15mr2653689ebb.27.1298991507466; Tue, 01 Mar 2011 06:58:27 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id q53sm556429eeh.22.2011.03.01.06.58.25 (version=SSLv3 cipher=OTHER); Tue, 01 Mar 2011 06:58:26 -0800 (PST) Sender: Andy Green Message-ID: <4D6D0991.8000203@warmcat.com> Date: Tue, 01 Mar 2011 14:58:25 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Pat McManus @Mozilla" References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <33B46028-223B-48C6-AA17-88FBE046E064@gmail.com> <4D6CA212.40204@warmcat.com> <1298990407.2498.671.camel@ds9.ducksong.com> In-Reply-To: <1298990407.2498.671.camel@ds9.ducksong.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 14:57:27 -0000 On 03/01/2011 02:40 PM, Somebody in the thread at some point said: > On Tue, 2011-03-01 at 07:36 +0000, Andy Green wrote: >> Don't forget a packet snooper is screwed by the mask already in current >> draft, it doesn't know if the packet is client -> server and has a >> 4-byte mask prepended, or server -> client and lacks it. > > Being transported on a stream based protocol, it is screwed whenever it > misses the handshake as it cannot be sure where the frame starts even in > the total absence of an asymmetric mask. If it has the handshake, then > there is no problem, if it misses it then it has to apply a pile of > heuristics - which still seems quite doable with masking (i.e. port > numbers, testing likely bytes for known opcodes, testing them with the > mask, etc..). Well, you're right. But two points ameliorate that, one is that the snooper only needs to achieve sync at the start of its snooping session and it won't lose it again if it's genuinely synced. The second point is the data on a websocket link is probably critical for latency so it will try to issue what it has quite quickly, and likely bursty, so sometimes there's no traffic. If the server makes a new frame at a packet boundary you are very likely to find a websocket header at the start of the first network packet after a period of being idle. If the data on the link doesn't fit that profile, eg it's audio that's always coming at a fixed rate, but the server spilling packets is done at a smaller amount of data than the frame length, yeah it'll be difficult to know what you're looking at. -Andy From jat@google.com Tue Mar 1 07:20:14 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDAFF3A68D9 for ; Tue, 1 Mar 2011 07:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.745 X-Spam-Level: X-Spam-Status: No, score=-105.745 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cBGoYGjkd2X for ; Tue, 1 Mar 2011 07:20:13 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 935783A68D0 for ; Tue, 1 Mar 2011 07:20:12 -0800 (PST) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p21FLF36020023 for ; Tue, 1 Mar 2011 07:21:15 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298992875; bh=koPiI46Dsevm8SPFk+8nZUXEdFk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=VITJ9pQSRsY1kapmAW4xTV1cewXeYQ7s/p5fUmahcpsMDahh+4eXl9z2FXNgv4jTn FxswhjckSVbLQ5+ChSQig== Received: from gwb15 (gwb15.prod.google.com [10.200.2.15]) by kpbe19.cbf.corp.google.com with ESMTP id p21FKmno024633 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 1 Mar 2011 07:21:13 -0800 Received: by gwb15 with SMTP id 15so2537172gwb.38 for ; Tue, 01 Mar 2011 07:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ZGBVuKLhi9mHQtSH3k0ZWbdpLIjDJXOCXBzXClL7lv8=; b=L8EM92iuaZ/I0+8/HahKc403qoi5KQPs+l1SK1jZTbCI9QecoOvkhFoEm+YJZzJiSR DvwdIiLMKY8Q3RzZCR0g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=kNqxlzAnIMzzZmFiYz8VwotJliBszlvLJ5COoQCAz27rX44eJIK91f82CSEJgynrUK HyzYJQIYBMLG4lffbTDw== Received: by 10.150.149.16 with SMTP id w16mr4589269ybd.217.1298992873208; Tue, 01 Mar 2011 07:21:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Tue, 1 Mar 2011 07:20:53 -0800 (PST) In-Reply-To: <4D6CB99D.8010801@warmcat.com> References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <4D6C9F6D.1030306@warmcat.com> <4D6CA34A.3050301@warmcat.com> <4D6CB2A8.7010707@warmcat.com> <4D6CB99D.8010801@warmcat.com> From: John Tamplin Date: Tue, 1 Mar 2011 10:20:53 -0500 Message-ID: To: Andy Green Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:20:14 -0000 On Tue, Mar 1, 2011 at 4:17 AM, Andy Green wrote: > Sorry I am not talking about any nesting but sequential normal frames. Fo= r example: > > =C2=A0[BINARY_OPCODE hdr + len][payload] > =C2=A0[EXTENDED_OPCODE hdr + len][payload (it is extension data, eg, comp= ression dictionary)] > =C2=A0[BINARY OPCODE hdr + len][payload] > =C2=A0... > > there is no problem with following the stream even if I don't understand = the extension, since it's a normal frame with length and payload defined ju= st a funny opcode. So what if the extension alters the interpretation of the payload? Say, the extension opcode is for super-compression that was negotiated? =C2=A0Are you suggesting that the compressed data follows in the next frame as if it were a regular frame? =C2=A0If so, how is it interpretable by something that doesn't understand the extension? Also, how does handle compositing extensions -- ie, the foo and bar extensions, each of which mutate the payload? =C2=A0If you had nested opcodes, you would have something like: BAR_OPCODE [bar(FOO_OPCODE [foo(TEXT_OPCODE, "hello")] )] If you make each extension a separate frame, I am not sure how you know how to interpret the result. > I am urged to read endless discussion... ^^ I am just saying these things were discussed before. > Except the uncertainty of having zero or more undefined bytes in the midd= le of every packet raises issues about moving masking key past it, and pars= ing the frame with snoopers, it's also kind of strange to see such an area = with at least no defined length control over it in a protocol. I really don't see much value in moving any extension data before the masking -- if we are masking the payload anyway, masking the extension data seems of little cost and protects us against an extension that allows attacker-controlled data. If no extensions are negotiated, the length is 0 (or 4 if the masking key is considered part of it on the client->server side) and you know exactly what goes there. =C2=A0If you later add support for an extension, the definition of that extension will say how to interpret the area, which might be zero length, a fixed length field, or some tag/value format that lets you skip over the extension. The endpoints have to have negotiated the extension for it to be present, so they have to know what it means. =C2=A0The only loser is transparent intermediaries (including packet sniffers) -- as mentioned in the current spec, they can't fragment or interpret the payload if an extension they don't understand is implemented. -- John A. Tamplin Software Engineer (GWT), Google From jat@google.com Tue Mar 1 07:27:57 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72EA03A68F6 for ; Tue, 1 Mar 2011 07:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.923 X-Spam-Level: X-Spam-Status: No, score=-105.923 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0mxZ2hSZ3TT for ; Tue, 1 Mar 2011 07:27:56 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 852C93A680C for ; Tue, 1 Mar 2011 07:27:56 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p21FSw4V027429 for ; Tue, 1 Mar 2011 07:28:58 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298993339; bh=WE4/cbkEiyOPYdavUNb9c0aPPUk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=hEQirBjfs1qBFuB6sTpexBWZI4hupi7hl+6h/7L4w35qcaeRpSYNehm03Duc0F6Ad N5Affn56QAHobkZLSSjmw== Received: from gwj18 (gwj18.prod.google.com [10.200.10.18]) by wpaz21.hot.corp.google.com with ESMTP id p21FSvp5021834 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 1 Mar 2011 07:28:57 -0800 Received: by gwj18 with SMTP id 18so2904983gwj.6 for ; Tue, 01 Mar 2011 07:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PspqRgZfUyF1JAsXFcVjip2vFDh5wSxGawlQnYsxNWk=; b=Yufk9X+f5ulYZaYqwf1W0ZSo7r4jZumnr6GSCJALEgfTABTyPH/pazI9N3f29QYX/p +RGK3Ys6eZbiesx81U5Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=YITzLbIccdLcac0PRYNVNSL6gS+/Wo5XYkphK4a7lX/KSbu23VmtGfN9Rr0IkWB7jl cx0BJDnKJjLBSMMzNRTQ== Received: by 10.150.198.11 with SMTP id v11mr8957637ybf.388.1298993337255; Tue, 01 Mar 2011 07:28:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Tue, 1 Mar 2011 07:28:37 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> From: John Tamplin Date: Tue, 1 Mar 2011 10:28:37 -0500 Message-ID: To: Simo.Veikkolainen@nokia.com Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: hybi@ietf.org, Gabriel.Montenegro@microsoft.com, gregw@intalio.com Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:27:57 -0000 On Tue, Mar 1, 2011 at 7:49 AM, wrote: > Being able to use a single heartbeat for multiple websocket connections > might also be beneficial, but not that critical. In cellular networks, waking > up the radio frequently is clearly worse than sending out some more > bytes once the radio is on. Clever operating systems might also offer an > API for queuing multiple heartbeat messages and sending them out at > one go. I don't see how the OS can get involved in it -- imagine the mobile browser has 10 apps running, and each of them have a hearbeat interval of 60s. If they happen to get started at regular intervals, you could wind up with the case of having to send a keepalive frame every 6 seconds. The OS only knows that packets are being sent over separate TCP connections -- how does it know it can delay some of those to avoid powering up the radio? If it delays some of them too much, the connection could be dropped as well. I really think all of this is a lot more complicated to get right, and I don't think we should try and put it into the base spec with no experience of deploying WebSocket on mobile devices to see how it is going to get used. Also, applications are likely to want their own timeout, so if you don't expose some way for apps to control the interval and what actually happens on it (perhaps a no-op call to their server), then you are likely to wind up with multiple layers of heartbeat messages. -- John A. Tamplin Software Engineer (GWT), Google From jat@google.com Tue Mar 1 07:31:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A973A695A for ; Tue, 1 Mar 2011 07:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.755 X-Spam-Level: X-Spam-Status: No, score=-105.755 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0RSy-hlPDBR for ; Tue, 1 Mar 2011 07:31:32 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 2B3303A6912 for ; Tue, 1 Mar 2011 07:31:32 -0800 (PST) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p21FWY8N029613 for ; Tue, 1 Mar 2011 07:32:34 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298993554; bh=iugbt8trnwjOAnYYBPcBsxVkSkM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ypkNcBIzbET1FlIJ28KkxFkNvsa+Q7LO6wZDqJBKGF2XbH1J5J/CMQIAU0PlPT/6y 3qDeLOfOEJQFkMx75VfgA== Received: from yxm8 (yxm8.prod.google.com [10.190.4.8]) by kpbe19.cbf.corp.google.com with ESMTP id p21FWW5b011224 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 1 Mar 2011 07:32:33 -0800 Received: by yxm8 with SMTP id 8so3291388yxm.40 for ; Tue, 01 Mar 2011 07:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=N5ERDSi+cAgqf+w1GtTSnBy6YqNM3/OIJ//HMjFgaj0=; b=rVRpVfExYB6uoXf3q05j8vwx5MzhHr/kEjRbJh/vLbajxKQAxRvaRSt3BBXSThR/P1 GkW5SeiCb7QU6ZmqT2Kw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=gFmD2KQoUi99Pb2RrFwJ4rL8m7+a0+xcG8V/rmvrGtMyGXTqLz7yGpYDAxqAXgE14Z BCVRkf8swMWdEnoB2A9A== Received: by 10.150.195.3 with SMTP id s3mr9020975ybf.274.1298993552181; Tue, 01 Mar 2011 07:32:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Tue, 1 Mar 2011 07:32:12 -0800 (PST) In-Reply-To: <4D6CEDA5.1060306@warmcat.com> References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> From: John Tamplin Date: Tue, 1 Mar 2011 10:32:12 -0500 Message-ID: To: Andy Green Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: Simo.Veikkolainen@nokia.com, hybi@ietf.org, Gabriel.Montenegro@microsoft.com, gregw@intalio.com Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:31:39 -0000 On Tue, Mar 1, 2011 at 7:59 AM, Andy Green wrote: > In practical terms it's probably easier and simpler to define and sell > people on the idea that there's another optional header that can be sent > out at the same time as the client and server handshake headers. > > Otherwise you'd have to use one of the scarce reserved opcodes for > setting this kind of thing or overload PING in an ugly way, etc. I would still like to move all control frames under a single CONTROL opcode, and use the first byte of the payload to indicate the control frame type -- I think it is useful to group control opcodes together since we specifically do things differently for control frames (they can't be fragmented, must use the short length format, and can be injected in the middle of a fragmented data message), plus it frees up some scarce opcodes and makes it nearly free to add more control opcodes. However, there has never seemed to be much support for the idea when proposed - maybe if we are wanting to add more control opcodes (including Hello), the idea becomes more interesting. -- John A. Tamplin Software Engineer (GWT), Google From andy.warmcat.com@googlemail.com Tue Mar 1 07:36:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487B53A695F for ; Tue, 1 Mar 2011 07:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8t9L9gJ7dphi for ; Tue, 1 Mar 2011 07:36:20 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 235383A695A for ; Tue, 1 Mar 2011 07:36:19 -0800 (PST) Received: by eye13 with SMTP id 13so2026417eye.31 for ; Tue, 01 Mar 2011 07:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bmtG2+TbpvWUIBiDsklrw8BhRGqM2sCojMKymvavVrA=; b=lAHnfFJMZ/wKfnQWX74Z9pyYlWArtSCmgxonwZSr80XJj/Wf+9HcPYPk18Z8MraYNa hmJBEt2vrqtwYl6KIuJQTt41Wc15vTWe/stPScVPciC6l+H6kNrO2edrdBzOPue7/Uxn desL8oFPgtGq86iBsnoTODWKbP+x34PIZI92Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=bQrMcp7hjaNaAa12q1hl1HXa6UUyH+O3oKgSXFo+t5bwssEGscioz4oKiWDGW6uPZh ZhjlNQCZNUS2BPpX8vpelH5fMi0o2FhpkfQyJNKfsVKpflDRgoKR1uZZfCPY+vC1K3p5 iOujOMWqljyECLq7r45+wK203wO/JnkyRIlf4= Received: by 10.213.28.209 with SMTP id n17mr3574799ebc.71.1298993842770; Tue, 01 Mar 2011 07:37:22 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id b52sm4317438eei.7.2011.03.01.07.37.21 (version=SSLv3 cipher=OTHER); Tue, 01 Mar 2011 07:37:22 -0800 (PST) Sender: Andy Green Message-ID: <4D6D12B0.8070502@warmcat.com> Date: Tue, 01 Mar 2011 15:37:20 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Tamplin References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <4D6C9F6D.1030306@warmcat.com> <4D6CA34A.3050301@warmcat.com> <4D6CB2A8.7010707@warmcat.com> <4D6CB99D.8010801@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:36:22 -0000 On 03/01/2011 03:20 PM, Somebody in the thread at some point said: > On Tue, Mar 1, 2011 at 4:17 AM, Andy Green wrote: >> Sorry I am not talking about any nesting but sequential normal >> frames. For example: >> >> [BINARY_OPCODE hdr + len][payload] [EXTENDED_OPCODE hdr + >> len][payload (it is extension data, eg, compression dictionary)] >> [BINARY OPCODE hdr + len][payload] ... >> >> there is no problem with following the stream even if I don't >> understand the extension, since it's a normal frame with length and >> payload defined just a funny opcode. > > So what if the extension alters the interpretation of the payload? Sorry John we have been talking at cross-purposes. > Say, the extension opcode is for super-compression that was > negotiated? Are you suggesting that the compressed data follows in > the next frame as if it were a regular frame? If so, how is it > interpretable by something that doesn't understand the extension? I didn't implement extension support yet, I went and checked and "payload length" includes the extension length inside the frame. ''The payload length is the length of the Extension data + the length of the Application Data. The length of the Extension data may be zero, in which case the Payload length is the length of the Application data.'' I thought there was no accounting for any extension data length which made it so strange to have it inside, but I was just under the wrong impression; even if you don't know what has gone on with extensions or how to interpret them, it doesn't make trouble for finding the next frame because the length, whatever it is, is accounted for in the "payload length". So no worries, sorry for the noise. -Andy From gregw@intalio.com Tue Mar 1 13:38:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD283A6AC9 for ; Tue, 1 Mar 2011 13:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJuHx3zDFJOD for ; Tue, 1 Mar 2011 13:38:41 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 93D953A6AB8 for ; Tue, 1 Mar 2011 13:38:41 -0800 (PST) Received: by vws6 with SMTP id 6so5228587vws.31 for ; Tue, 01 Mar 2011 13:39:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.97.130 with SMTP id ea2mr5229835vdb.230.1299015584461; Tue, 01 Mar 2011 13:39:44 -0800 (PST) Received: by 10.52.165.129 with HTTP; Tue, 1 Mar 2011 13:39:44 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> Date: Wed, 2 Mar 2011 08:39:44 +1100 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: multipart/alternative; boundary=20cf307cfc7878352a049d72a2a3 Cc: Simo.Veikkolainen@nokia.com, hybi@ietf.org, Gabriel.Montenegro@microsoft.com Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 21:38:42 -0000 --20cf307cfc7878352a049d72a2a3 Content-Type: text/plain; charset=ISO-8859-1 On 2 March 2011 02:32, John Tamplin wrote: > I would still like to move all control frames under a single CONTROL > opcode, and use the first byte of the payload to indicate the control > frame type -- I think it is useful to group control opcodes together > since we specifically do things differently for control frames (they > can't be fragmented, must use the short length format, and can be > injected in the middle of a fragmented data message), plus it frees up > some scarce opcodes and makes it nearly free to add more control > opcodes. I really don't think opcode space is going to be a problem.... it is so hard to get agreement on even basic features, I don't see any rampant featurism about to start soon. But I do think partitioning the opcodes is a good idea: frame-opcode = %x0 ; continuation frame / %x1 ; text frame / %x2 ; binary frame / %x3-7 ; reserved / frame-control-opcode frame-control-opcode = %x8 ; ping / %x9 ; pong / %xA-E ; reserved / %xF ; close cheers --20cf307cfc7878352a049d72a2a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2 March 2011 02:32, John Tamplin <jat@google.com> wrote:
> I would still like to move all= control frames under a single CONTROL
> opcode, and use the first by= te of the payload to indicate the control
> frame type -- I think it is useful to group control opcodes together> since we specifically do things differently for control frames (they=
> can't be fragmented, must use the short length format, and can= be
> injected in the middle of a fragmented data message), plus it frees up=
> some scarce opcodes and makes it nearly free to add more control> opcodes.

I really don't think opcode space is going to be= a problem.... it is so hard to get agreement on even basic features, I don= 't see any rampant featurism about to start soon.

But I do think partitioning the opcodes is a good idea:

frame-opcode =3D %x0 ; continuation frame
=A0 =A0 =A0 =A0 =A0 = =A0=A0 / %x1 ; text frame
=A0 =A0 =A0 =A0= =A0 =A0=A0 / %x2 ; binary frame
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 / %x3-7 ; reserved
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 / frame-control-opcode

frame-control-opcode = =3D %x8 ; ping
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 / %x9 ; pong
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 / %xA-E ; reserved
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 / %xF ; close
 =A0=A0 <= br>
cheers

--20cf307cfc7878352a049d72a2a3-- From theturtle32@gmail.com Tue Mar 1 13:38:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3DA23A6AEF for ; Tue, 1 Mar 2011 13:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCG2ynreL524 for ; Tue, 1 Mar 2011 13:38:59 -0800 (PST) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by core3.amsl.com (Postfix) with ESMTP id 2EC733A6AF1 for ; Tue, 1 Mar 2011 13:38:58 -0800 (PST) Received: by gwj22 with SMTP id 22so2879027gwj.27 for ; Tue, 01 Mar 2011 13:40:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=2WsLRBmiKTc13JUk/3dyLnylG4DexZxxAmE+bjloBXA=; b=hD0SbHysiwLS3U87XKpX1cMbitZw1Mgemm0F0xC91o483PgfV22VOSNB1hbB0TUWTb KIqboBULxTlnx39KZe0AX9CiVQ1kkh0OesipbzWnhdffjkvXcbhSEe6X/nobmxAkdkgj MOgzpOjJ2AhAOp0sFiMUEpMQRBXwLNIDwpVwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=kYlrBxlGF6sch90vHc1i6BjBI12Zu6QXuvReigL7AcNQlDFvcT8oRVbhT7bK/XOvm0 LfaGTcoBNiMevNT41bJBvBNasIJYnonc1fuh8eTYZHOR+utZbuDVYVOEXjqPQUjkl5F+ iL1htDY3i42tTbYElFYvD2jz7SgjxIgnziUeE= Received: by 10.150.172.3 with SMTP id u3mr9470989ybe.409.1299015601777; Tue, 01 Mar 2011 13:40:01 -0800 (PST) Received: from [10.38.10.231] ([166.205.138.239]) by mx.google.com with ESMTPS id 14sm218564yhl.22.2011.03.01.13.39.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2011 13:40:00 -0800 (PST) References: <20110301060349.GC9463@1wt.eu> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148) From: Brian McKelvey Date: Tue, 1 Mar 2011 13:39:50 -0800 To: John Tamplin Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" , "gregw@intalio.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 21:38:59 -0000 I agree. For mobile developers, for now it seems reasonable that they could= use their own custom scheme in coordination with their own server implement= ation if they really need to specifically tune the heartbeat interval for no= w, assuming that they're writing a native app and not a mobile web app, and c= ontrol their own server, which seems likely in this scenario. Long running b= ackground web apps on mobile that continuously maintain a background websock= et connection is very unlikely to be a possibility right now for other reaso= ns. Once we learn more about how this all works together in practice we can defi= ne an extension or update to the protocol then. Brian Sent from my iPhone On Mar 1, 2011, at 7:28 AM, John Tamplin wrote: > I really think all of this is a lot more complicated to get right, and > I don't think we should try and put it into the base spec with no > experience of deploying WebSocket on mobile devices to see how it is > going to get used. From gregw@intalio.com Tue Mar 1 14:50:16 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 675D53A6B0B for ; Tue, 1 Mar 2011 14:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcLMScs-Yp4H for ; Tue, 1 Mar 2011 14:50:15 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 455303A6908 for ; Tue, 1 Mar 2011 14:50:15 -0800 (PST) Received: by vws6 with SMTP id 6so5296812vws.31 for ; Tue, 01 Mar 2011 14:51:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.173.78 with SMTP id bi14mr6767913vdc.30.1299019878523; Tue, 01 Mar 2011 14:51:18 -0800 (PST) Received: by 10.52.165.129 with HTTP; Tue, 1 Mar 2011 14:51:18 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> Date: Wed, 2 Mar 2011 09:51:18 +1100 Message-ID: From: Greg Wilkins To: Brian McKelvey Content-Type: multipart/alternative; boundary=bcaec51b98956a61ab049d73a294 Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 22:50:16 -0000 --bcaec51b98956a61ab049d73a294 Content-Type: text/plain; charset=ISO-8859-1 On 2 March 2011 08:39, Brian McKelvey wrote: > > Once we learn more about how this all works together in practice we can > define an extension or update to the protocol then. > > But do you think we should be disclosing idle timeouts at this stage, to help us develop those future plugins. For example if we see that the clients are declaring idle timeouts of 300s and the servers declaring 200s, yet we see connections closing frequently at a 60s, then we will know that we have an intermediary with it's own idle timeout and that will shape the design of any future keep alives. So currently the proposal is simply to disclose timeouts (and buffer sizes). cheers --bcaec51b98956a61ab049d73a294 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2 March 2011 08:39, Brian McKelvey <theturtle32@gm= ail.com> wrote:

Once we learn more about how this all works together in practice we can def= ine an extension or update to the protocol then.


But do you think we should be disclosing idle tim= eouts at this stage, to help us develop those future plugins.

For ex= ample if we see that the clients are declaring idle timeouts of 300s and th= e servers declaring 200s, yet we see connections closing frequently at a 60= s, then we will know that we have an intermediary with it's own idle ti= meout and that will shape the design of any future keep alives.

So currently the proposal is simply to disclose timeouts (and buffer si= zes).=A0

cheers

--bcaec51b98956a61ab049d73a294-- From jat@google.com Tue Mar 1 15:00:11 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC1DE3A6B0F for ; Tue, 1 Mar 2011 15:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.763 X-Spam-Level: X-Spam-Status: No, score=-105.763 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv+mh4b4er6L for ; Tue, 1 Mar 2011 15:00:11 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id A21093A6B0E for ; Tue, 1 Mar 2011 15:00:10 -0800 (PST) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p21N1D9V008617 for ; Tue, 1 Mar 2011 15:01:13 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299020473; bh=q1q9NZG3JyIbOiKdHQDKW1i/o0w=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=wqKFia2sz4SfSNcLD0zBRuBkgyYmyhAvuF5uHRY7VG1PDuQ7mtXktM0tMtG+jL0mH 5fsJRLC20ecqC7VDPYwKQ== Received: from gyg10 (gyg10.prod.google.com [10.243.50.138]) by kpbe16.cbf.corp.google.com with ESMTP id p21N1BJD025032 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 1 Mar 2011 15:01:11 -0800 Received: by gyg10 with SMTP id 10so2949554gyg.7 for ; Tue, 01 Mar 2011 15:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LmWCLjiQ0XBYtT5fMCGkvDh+KmMFsZd2EkQzY1gJ/14=; b=f/C8F2oHV4lnYaAE5lDeVwj9wIh008WQB2D8p37TLnfhGJ1R7O2C6HpC980A2FJn5y jxuham5nE9BUiTxfrt0w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=GNsrMxMwQ6yWKP7rWj0YxYKOiMj3suINPaXxaZEd7ygHyaQgXKkReRVLp7yF6uwVAd jz/nIzaprO6jK3Ze9VZg== Received: by 10.150.165.21 with SMTP id n21mr9446658ybe.445.1299020471108; Tue, 01 Mar 2011 15:01:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Tue, 1 Mar 2011 15:00:51 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> From: John Tamplin Date: Tue, 1 Mar 2011 18:00:51 -0500 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd56f86bc86e3049d73c59b X-System-Of-Record: true Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 23:00:11 -0000 --000e0cd56f86bc86e3049d73c59b Content-Type: text/plain; charset=UTF-8 On Tue, Mar 1, 2011 at 5:51 PM, Greg Wilkins wrote: > But do you think we should be disclosing idle timeouts at this stage, to > help us develop those future plugins. > > For example if we see that the clients are declaring idle timeouts of 300s > and the servers declaring 200s, yet we see connections closing frequently at > a 60s, then we will know that we have an intermediary with it's own idle > timeout and that will shape the design of any future keep alives. > > So currently the proposal is simply to disclose timeouts (and buffer > sizes). > But what exactly would we be collecting? If there is no application control over those values, it will simply be what the user agents send by default (if they do at all). Also, how would we actually collect the data? I just don't see it buying much to put it in before we have anything to do with it. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd56f86bc86e3049d73c59b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 1, 2011 at 5:51 PM, Greg Wilkins <gregw@intalio.com> wrote:
But do you think we should be disclosing id= le timeouts at this stage, to help us develop those future plugins.

= For example if we see that the clients are declaring idle timeouts of 300s = and the servers declaring 200s, yet we see connections closing frequently a= t a 60s, then we will know that we have an intermediary with it's own i= dle timeout and that will shape the design of any future keep alives.

So currently the proposal is simply to disclose timeouts (and buffer si= zes).=C2=A0

But what exac= tly would we be collecting? =C2=A0If there is no application control over t= hose values, it will simply be what the user agents send by default (if the= y do at all). =C2=A0Also, how would we actually collect the data?

I just don't see it buying much to put it in before we h= ave anything to do with it.

--
John A. Tamplin
= Software Engineer (GWT), Google
--000e0cd56f86bc86e3049d73c59b-- From theturtle32@gmail.com Tue Mar 1 15:01:47 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49603A6B0E for ; Tue, 1 Mar 2011 15:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1aDGw6aN8jQ for ; Tue, 1 Mar 2011 15:01:47 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id E69E73A6B0F for ; Tue, 1 Mar 2011 15:01:46 -0800 (PST) Received: by yic13 with SMTP id 13so429985yic.31 for ; Tue, 01 Mar 2011 15:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=ol3i1Gmr6m6X/Ei6L5AZjbIoG+X2rfPIZptnLIwfTFY=; b=F1sOHptGG5rKOHgtWxDAOXQU5vMZJqMJNUInzbDtKcU9Rh4g5+tN75qXXzppCLB64y 764ogtbb95W8H3rOexEVjrgr2YACtVNXQ9Z04VeGamRbGbKlifxfmqUHhLZhBAcU1v3P XU03W+1hoj40auNfQ+b5O/azuY0z1bp9kIjcY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=OkhJliMl+4oBc2ilnbJmbv8eLvuc+AV8pWR3+j0J7FS+v3RLSGowhVjGp57Hhy+u9O KTHUWEk9jueUssJ+aTeKDlTmsx5S6/TLOAMaK5k5VgkeplOct9UTWbBD/USck18XAgGX 2bvv+fiEQf16QyjRsU5TR4Wv6ZGYqRe16SDW4= Received: by 10.90.98.6 with SMTP id v6mr10208919agb.3.1299020570671; Tue, 01 Mar 2011 15:02:50 -0800 (PST) Received: from [10.38.10.231] ([166.205.138.239]) by mx.google.com with ESMTPS id 37sm7130847anr.4.2011.03.01.15.02.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2011 15:02:49 -0800 (PST) References: <20110301060349.GC9463@1wt.eu> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <06E2327E-3CD0-447C-8A1B-132486D40466@gmail.com> X-Mailer: iPhone Mail (8C148) From: Brian McKelvey Date: Tue, 1 Mar 2011 15:02:38 -0800 To: Greg Wilkins Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 23:01:47 -0000 I'm not opposed to it. It seems super simple to me especially if it's just i= nformational and there is no requirement to act on the information. Someone= developing an application where it is more important (such as a mobile app)= can choose to act on the data in the fields in their implementation, and/or= implement the heartbeat at the application level. If it's just to provide data points for future evaluation and optimization i= t seems like a pretty low cost. The proposal ought to be simple enough that i don't think it should reasonab= ly meet too much resistance, especially if the fields are optional and if so= meone submits a proposal for how to word it in the draft. Fwiw, I'd like to see this in the http headers rather than as some kind of h= ello frame. Brian Sent from my iPhone On Mar 1, 2011, at 2:51 PM, Greg Wilkins wrote: > But do you think we should be disclosing idle timeouts at this stage, to h= elp us develop those future plugins. From theturtle32@gmail.com Tue Mar 1 15:04:50 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B4383A6B1F for ; Tue, 1 Mar 2011 15:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QJET97RiDWi for ; Tue, 1 Mar 2011 15:04:48 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 7C6BE3A6B1B for ; Tue, 1 Mar 2011 15:04:48 -0800 (PST) Received: by iwl42 with SMTP id 42so5167478iwl.31 for ; Tue, 01 Mar 2011 15:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=yPKDPN8Rnr3oduwvLd0FFDND9FqmUVu9DPF4ro7gnB4=; b=SjqndMjAe+WlCKyoZEMyMYY8H2y2/o0i2eMdHoClNW4Gszju7gnL+RXpvUZKQ2aukC LA8lIZiHodGryf6TT8B4FIxUMryrmxpa6eUm+1ur8AsaKuqwt91lmt7BzPIPKxYVuIJR TvzgX+wnUnWhiFlfTDYFsj2OUSrvSiI4XR7uo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=DXmEEOzCaDHNlqb7tBWZeJtl4uJ2PG6jJ74/qUZsFG+NOsyGg7/I6VUyKba+0akcMR 7OGxTSjPD64SXHeUQAeSqXXgUNd0CAQUj3VggJI7PdLt6i01STVM94IgCrEURKIknoQz mf1VlHgyuqOAFYBPVe9OWZqZIBbrKl2j6WLx0= Received: by 10.231.207.66 with SMTP id fx2mr6783759ibb.108.1299020752589; Tue, 01 Mar 2011 15:05:52 -0800 (PST) Received: from [10.38.10.231] ([166.205.138.239]) by mx.google.com with ESMTPS id gy41sm6100206ibb.5.2011.03.01.15.05.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2011 15:05:52 -0800 (PST) References: <20110301060349.GC9463@1wt.eu> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <96890454-469F-441C-806E-699EA564FFF0@gmail.com> X-Mailer: iPhone Mail (8C148) From: Brian McKelvey Date: Tue, 1 Mar 2011 15:05:43 -0800 To: John Tamplin Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" , Greg Wilkins Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 23:04:50 -0000 Right. I kindof feel the same way but it seems simple and unobtrusive enoug= h that if Greg wanted to be able to write his server to log the data for res= earch purposes and be able to provide some amount of concrete information to= the dialog in the future, im not opposed. Sent from my iPhone On Mar 1, 2011, at 3:00 PM, John Tamplin wrote: > I just don't see it buying much to put it in before we have anything to do= with it. From gregw@intalio.com Tue Mar 1 15:28:02 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3D823A6B20 for ; Tue, 1 Mar 2011 15:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.708 X-Spam-Level: X-Spam-Status: No, score=-2.708 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDapBYd+5IN2 for ; Tue, 1 Mar 2011 15:28:01 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id A35553A6998 for ; Tue, 1 Mar 2011 15:28:01 -0800 (PST) Received: by vws6 with SMTP id 6so5329033vws.31 for ; Tue, 01 Mar 2011 15:29:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.91.230 with SMTP id ch6mr5695392vdb.270.1299022145089; Tue, 01 Mar 2011 15:29:05 -0800 (PST) Received: by 10.52.165.129 with HTTP; Tue, 1 Mar 2011 15:29:04 -0800 (PST) In-Reply-To: <1298990267.2498.668.camel@ds9.ducksong.com> References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> Date: Wed, 2 Mar 2011 10:29:04 +1100 Message-ID: From: Greg Wilkins To: "Pat McManus @Mozilla" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 23:28:03 -0000 On 2 March 2011 01:37, Pat McManus @Mozilla wrote: > > * The mask is incredibly cheap to implement. You can do XOR at the rate > of your memory bandwidth. The benefit to "optimizing it away" is at best > marginal even in high bandwidth scenarios. That is a hand waive.=A0 It is neither incredibly cheap nor simple when it is munged in with the framing. For example In java, we have two type of buffer: direct (kernel space) and indirect (user space). Typically by the time we are at the level of sending framing, we mostly would like to be dealing with kernel space buffers, perhaps doing a gather write of the headers with the content.=A0=A0=A0 But masking in the framing means that we need to copy kernal data back into user space, mask and then put it back to kernel space - UGH!=A0 If SSL is involved, it get's even uglier. With incoming data, there is a difficulty looking at kernel space buffers and it is best to do bulk operations on them.=A0 Masking the framing means that we needs to copy the data to user space, often only to discover we don't have the full frame and have to wait for the rest of it (now holding both a kernel and a user space buffer). If we mask the payload, then because it is=A0 exchanged with the application, it is naturally in user space=A0 and we know have been fully received.=A0=A0 It then is a relatively simple and cheap exercise to XOR the entire payload. > --> consistent application of masking makes websockets a generally more > robust protocol at an insignificant cost. Exactly!=A0=A0 So having masking be just an exemplar of an extension that can mutate payload is great way to achieve consistency in the protocol. > Creating a path for the defence to be disabled is penny wise pound foolis= h. It is an entirely different question if you make the masking extension optional or not - Having the ability to turn it off does not mean that you have to turn it off.=A0=A0=A0 It is wrong to present an inflexible special case based design as a security benefit. regards From gregw@intalio.com Tue Mar 1 15:36:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E2FF3A6998 for ; Tue, 1 Mar 2011 15:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6qG4CUNGxQG for ; Tue, 1 Mar 2011 15:36:03 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 1A7BC3A6B21 for ; Tue, 1 Mar 2011 15:36:02 -0800 (PST) Received: by vws6 with SMTP id 6so5335842vws.31 for ; Tue, 01 Mar 2011 15:37:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.157.100 with SMTP id wl4mr12354745vdb.190.1299022626826; Tue, 01 Mar 2011 15:37:06 -0800 (PST) Received: by 10.52.165.129 with HTTP; Tue, 1 Mar 2011 15:37:06 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> Date: Wed, 2 Mar 2011 10:37:06 +1100 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 23:36:04 -0000 On 2 March 2011 10:00, John Tamplin wrote: > On Tue, Mar 1, 2011 at 5:51 PM, Greg Wilkins wrote: >> >> But do you think we should be disclosing idle timeouts at this stage, to >> help us develop those future plugins. >> >> For example if we see that the clients are declaring idle timeouts of 30= 0s >> and the servers declaring 200s, yet we see connections closing frequentl= y at >> a 60s, then we will know that we have an intermediary with it's own idle >> timeout and that will shape the design of any future keep alives. >> >> So currently the proposal is simply to disclose timeouts (and buffer >> sizes). > > But what exactly would we be collecting? =A0If there is no application co= ntrol > over those values, it will simply be what the user agents send by default > (if they do at all). Indeed - I think a lot more thought would be needed before exposing such information to the application. The information would be known only to the websocket layers of the client and the server. I assume that initially they would simply be ignored or logged. Perhaps the servers could align their idle times with that of the client. > =A0Also, how would we actually collect the data? Logs > I just don't see it buying much to put it in before we have anything to d= o with it. I don't see how any future keep alive mechanism will be able to be well designed without the knowledge gained from such disclosures. It will have to be based on guess work, or we will just set a stupidly low timeout value and continue to waste bandwidth. If we start declaring timeouts now, then intermediaries written to understand WS will know that timeouts will eventually be explicitly managed. They may then be encouraged to declare their own timeouts or to respect the server/client timeouts. I know that there is no perfect solution here - but giving up and just pinging every 30s, does not feel like the right approach. From jat@google.com Tue Mar 1 15:56:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DD833A6B4E for ; Tue, 1 Mar 2011 15:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.771 X-Spam-Level: X-Spam-Status: No, score=-105.771 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnmaK2HAvUGA for ; Tue, 1 Mar 2011 15:56:47 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 297F33A6962 for ; Tue, 1 Mar 2011 15:56:45 -0800 (PST) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p21NvmkC015698 for ; Tue, 1 Mar 2011 15:57:49 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299023869; bh=eVcxEY9zCSwycukYXHFhGDBMnNo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=o5Nv6iGcMytytUznruEuQ1a6ZINACAul/QxLSPUDDDWJw5eLlt5scsSOQTMedlWrx 0L+LB6HSR9uhpm8wilzEQ== Received: from ywg4 (ywg4.prod.google.com [10.192.7.4]) by kpbe16.cbf.corp.google.com with ESMTP id p21NtnNU001292 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 1 Mar 2011 15:57:47 -0800 Received: by ywg4 with SMTP id 4so1859804ywg.10 for ; Tue, 01 Mar 2011 15:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2LbRX6mN5KXWLJAvvR3X40T91k+5xvfrkiIL9OzEfZs=; b=s/YuHQv6Oi2hvsKpfZ2JQY0AKTZiXG4+BqBFieohHpZctZKW91YYt1e39UP14ILPDK ySiV/pTafyxR/QCH8DPQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=PYETgKagc3XfD8SRETcdGOjhtqxIgC//c7HYXxOeVSzB9CHZHoW2ThF/5yfSBLBUyZ dHGpSruiLmh1kaKtrfcg== Received: by 10.150.73.32 with SMTP id v32mr3387087yba.46.1299023867179; Tue, 01 Mar 2011 15:57:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Tue, 1 Mar 2011 15:57:27 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> From: John Tamplin Date: Tue, 1 Mar 2011 18:57:27 -0500 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd5912628735b049d749073 X-System-Of-Record: true Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 23:56:48 -0000 --000e0cd5912628735b049d749073 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 1, 2011 at 6:37 PM, Greg Wilkins wrote: > > But what exactly would we be collecting? If there is no application > control > > over those values, it will simply be what the user agents send by default > > (if they do at all). > > Indeed - I think a lot more thought would be needed before exposing > such information to the application. > > The information would be known only to the websocket layers of the > client and the server. I assume that initially they would simply be > ignored or logged. Perhaps the servers could align their idle times > with that of the client. But my point is you will just be collecting what we already know (assuming any user agents provide the information) -- default compiled-in values that are in the user agents. So, I don't see the benefit of sending and collecting something that has no API to change. At the end of it, there will be no new information gathered, and in the meantime we just sent lots of constant bytes over the wire. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd5912628735b049d749073 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 1, 2011 at 6:37 PM, Greg Wilkins <gregw@intalio.com> wrote:
> But what exactly would we be collecting? =C2=A0If th= ere is no application control
> over those values, it will simply be what the user agents send by defa= ult
> (if they do at all).

Indeed - I think a lot more thought would be needed before exposing such information to the application.

The information would be known only to the websocket layers of the
client and the server. =C2=A0I assume that initially they would simply be ignored or logged. =C2=A0Perhaps the servers could align their idle times with that of the client.

But my point is yo= u will just be collecting what we already know (assuming any user agents pr= ovide the information) -- default compiled-in values that are in the user a= gents. =C2=A0So, I don't see the benefit of sending and collecting some= thing that has no API to change. =C2=A0At the end of it, there will be no n= ew information gathered, and in the meantime we just sent lots of constant = bytes over the wire.=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd5912628735b049d749073-- From mcmanus@ducksong.com Tue Mar 1 16:00:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2483A6B54 for ; Tue, 1 Mar 2011 16:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WpJ3jcJ2Hla for ; Tue, 1 Mar 2011 16:00:47 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id B01D03A6962 for ; Tue, 1 Mar 2011 16:00:47 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id B332610442; Tue, 1 Mar 2011 19:01:51 -0500 (EST) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id DEA06101F6; Tue, 1 Mar 2011 19:01:44 -0500 (EST) From: "Pat McManus @Mozilla" To: Greg Wilkins In-Reply-To: References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Mar 2011 19:01:21 -0500 Message-ID: <1299024081.2498.1020.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:00:48 -0000 On Wed, 2011-03-02 at 10:29 +1100, Greg Wilkins wrote: > On 2 March 2011 01:37, Pat McManus @Mozilla wrote: > > > > * The mask is incredibly cheap to implement. You can do XOR at the rate > > of your memory bandwidth. The benefit to "optimizing it away" is at best > > marginal even in high bandwidth scenarios. > > That is a hand waive. It is not. It is a statement that XOR runs at the rate of memory bandwidth and that is plenty fast enough; the details of your implementation not withstanding. I'm not swayed by an argument that in 2011 an Internet protocol security feature should be able to be disabled, and thus the attack surface increased, in order to save the cost of a simple XOR on the data stream. It is a bad trade off. I was more tempted by the savings when we were potentially doing complicated hashes or even AES - but with XOR it just isn't interesting to me. I have similar feelings on not masking the header. Greg, I don't expect you to agree. But you said that such an argument hadn't been made - and this is the core of mine. -- http://www.getfirefox.com/ From theturtle32@gmail.com Tue Mar 1 16:08:38 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C5E3A6A45 for ; Tue, 1 Mar 2011 16:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94JEqam+tFOL for ; Tue, 1 Mar 2011 16:08:38 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 02B373A6BFD for ; Tue, 1 Mar 2011 16:08:12 -0800 (PST) Received: by ywi6 with SMTP id 6so2170775ywi.31 for ; Tue, 01 Mar 2011 16:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=lyFDQT85Dcd0ozdWDkEDRgpAOIKJINoeQMWiNeEAepA=; b=U6JJKRmO/vDk8jphcOgampLgUPMq1hUmGhpaDV2qzVxPZXkvjKmlKqTIT8+XM8sm3N Y6y0AutZ5PrHf0SvQvPe9x0mnqZBj29MlQeL4nVP2Di9+CxyNKfnr6MTbscgNBveZkrY /cfzLVcYmj48/1m8QKmNf1QSXbIkBt75mNCZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=MrJ8DTwsjB92YC4r0waIMLtquNMMUQKFb84oAqhidJE32O1hReIADXRSZm9O3Z+Nom 31XJANvPdKv5JPHQ+C7JiBNR+Qs3qNBKRtMKkB00jBFyf69GXI86isX5LvcKqqywCk3X eUmlJ5wfs+ggGOYYdT9l6YajQBG5cSm8RZWUg= Received: by 10.151.112.14 with SMTP id p14mr9616865ybm.118.1299024556822; Tue, 01 Mar 2011 16:09:16 -0800 (PST) Received: from [10.38.10.231] ([166.205.138.239]) by mx.google.com with ESMTPS id u4sm227305ybe.9.2011.03.01.16.09.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2011 16:09:15 -0800 (PST) References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE 46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148) From: Brian McKelvey Date: Tue, 1 Mar 2011 16:09:07 -0800 To: Greg Wilkins Cc: Hybi Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:08:39 -0000 I completely agree. I dont mean to be hostile, but the browser vendors are t= he ones concerned about this security issue and indeed exploits that leverag= e browsers have been the specific attack vector that masking is intended to p= rotect against in all the discussions on this list to date. Therefore, the o= nus for making sure that client data is masked should lie squarely on the sh= oulders of the browser vendors. That really is common sense, and any argume= nt to the contrary holds no water, IMO. The only real argument I can recall= for making servers require it is just in case there is a bug in some browse= r that somehow allows unmasked data to be sent. That is nothing short of a c= op-out. That being said, I would like to see masking apply to the payload and extens= ion data only, whether or not it's required (I care more that the masking is= applied only to the payload/extension data than whether its required or not= ), and implementing it as a (potentially) mandatory extension seems to me a c= lean way to accomplish the stated goal. The likelihood that a viable attack= accomplishing anything of gravity could be mounted using only the manipulab= le fields in the framing (length etc) is so remote that it's laughable, but f= rustratingly, few people seem to be willing to come out and say that directl= y, even though many have alluded unmistakably to the fact that they agree. Brian Sent from my iPhone On Mar 1, 2011, at 3:29 PM, Greg Wilkins wrote: > It is an entirely different question if you make the masking extension > optional or not - Having the ability to turn it off does not mean that > you have to turn it off. It is wrong to present an inflexible > special case based design as a security benefit. >=20 From gregw@intalio.com Tue Mar 1 16:23:49 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70713A6ADF for ; Tue, 1 Mar 2011 16:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ork-FAsNURmM for ; Tue, 1 Mar 2011 16:23:47 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 653703A6C0E for ; Tue, 1 Mar 2011 16:23:06 -0800 (PST) Received: by vxg33 with SMTP id 33so5292921vxg.31 for ; Tue, 01 Mar 2011 16:24:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.160.8 with SMTP id xg8mr11714810vdb.310.1299025427565; Tue, 01 Mar 2011 16:23:47 -0800 (PST) Received: by 10.52.165.129 with HTTP; Tue, 1 Mar 2011 16:23:47 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> Date: Wed, 2 Mar 2011 11:23:47 +1100 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:23:49 -0000 On 2 March 2011 10:57, John Tamplin wrote: > But my point is you will just be collecting what we already know (assumin= g > any user agents provide the information) -- default compiled-in values th= at > are in the user agents. We don't already know it. I don't even know my own default values, as they are taken from configuration that every deployment of jetty may change. More importantly, I do know that users do change the values. Those that are concerned about working no matter what typically have 30s timeouts. Others that are working in intranets or don't care too much about a non zero drop out rate, will often have timeouts up to 250s. I have no idea what the timeouts are in chrome, FF, opera etc. Are they the same? Are they configurable? Are they dynamic? What about libwebsocket? what about home grown clients? This is a real problem for comet servers already and I don't see why websocket will be any different. >=A0So, I don't see the benefit of sending and > collecting something that has no API to change. =A0At the end of it, ther= e > will be no new information gathered, and in the meantime we just sent lot= s > of constant bytes over the wire. Just because data is not available to the application, does not mean that it is not meaningful. The bytes are neither known or constant. I'm not sure that a Sec-Websocket-IdleTimeout: 200 in the handshake could be described as "lots of bytes". It will certainly be less bytes than if connection keep getting closed due to no know idle timeouts and the client just opens then up again. regards From jat@google.com Tue Mar 1 16:30:41 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9F53A6A55 for ; Tue, 1 Mar 2011 16:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.779 X-Spam-Level: X-Spam-Status: No, score=-105.779 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CATyUE8zNg+v for ; Tue, 1 Mar 2011 16:30:40 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id CFEE23A6A30 for ; Tue, 1 Mar 2011 16:30:39 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p220VgvJ026948 for ; Tue, 1 Mar 2011 16:31:43 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299025903; bh=9sWARZVaKHubHaWk5V5PtohBC9U=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=nVd1LJJin/TsqojJodEpTpccn1evT80/PucW6xzF5wCEAvrFKvrwRzo0TgVTsqWwX hipmXrPUT4tTy5MqTG5sA== Received: from yws5 (yws5.prod.google.com [10.192.19.5]) by wpaz21.hot.corp.google.com with ESMTP id p220VTdE026776 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 1 Mar 2011 16:31:41 -0800 Received: by yws5 with SMTP id 5so2416587yws.0 for ; Tue, 01 Mar 2011 16:31:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hDYDbEJR9VtPonjtkDUBeuaWJlITPW5saQEsDg6YAoY=; b=Skfqhh/f4+C1qoGaDxwjWZpQuldU+q2LYIECsqpUyMSnrTuSjoYKIqa6Kyudl35fw0 LR44gYhXfCileXnicH7Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=fIGqLdrmjl/5PZWbYXkMkCNea9B3ySY6YqIYIn2fO5H6lqdvSaqn/jXiFMqyGwdaPP cKQars3cwj0kqVZjMNPQ== Received: by 10.150.165.21 with SMTP id n21mr9534866ybe.445.1299025901162; Tue, 01 Mar 2011 16:31:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Tue, 1 Mar 2011 16:31:21 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> From: John Tamplin Date: Tue, 1 Mar 2011 19:31:21 -0500 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd56f86649072049d750947 X-System-Of-Record: true Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:30:41 -0000 --000e0cd56f86649072049d750947 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 1, 2011 at 7:23 PM, Greg Wilkins wrote: > We don't already know it. I don't even know my own default values, > as they are taken from configuration that every deployment of jetty > may change. > More importantly, I do know that users do change the values. Those > that are concerned about working no matter what typically have 30s > timeouts. Others that are working in intranets or don't care too much > about a non zero drop out rate, will often have timeouts up to 250s. > If they don't actually do anything, why would anyone go change it? > I have no idea what the timeouts are in chrome, FF, opera etc. Are > they the same? Are they configurable? Are they dynamic? > What about libwebsocket? what about home grown clients? > Right now they don't exist because the current spec doesn't have them. If the spec were to require browsers to send timeout values that aren't actually used, it seems likely they would send some fixed value. I'm not sure that a > Sec-Websocket-IdleTimeout: 200 > > in the handshake could be described as "lots of bytes". > It will certainly be less bytes than if connection keep getting closed > due to no know idle timeouts and the client just opens then up again. > I mean collectively lots of bytes across all the WebSocket connections until a standard exists that makes use of them. Since as proposed the timeouts aren't to be used for anything, I don't see how providing them can prevent any connections from being closed. To be clear, I am only talking about the time between when they are put in the spec (now, as you are suggesting) and when they are actually used for some purpose (some arbitrary time in the future, since you appear to agree we don't want to wait and try and define how to do something useful with them in the base spec). -- John A. Tamplin Software Engineer (GWT), Google --000e0cd56f86649072049d750947 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 1, 2011 at 7:23 PM, Greg Wilkins <gregw@intalio.com> wrote:
We don't already know it. =C2=A0 I don't even kno= w my own default values,
as they are taken from configuration that every deployment of jetty
may change.
More importantly, I do know that users do change the values. =C2=A0Those that are concerned about working no matter what typically have 30s
timeouts. =C2=A0Others that are working in intranets or don't care too = much
about a non zero drop out rate, will often have timeouts up to 250s.

If they don't actually do anything, why w= ould anyone go change it?=C2=A0
=C2=A0
I have no idea what the timeouts are in chrome, FF, opera etc. =C2=A0 Are they the same? =C2=A0 Are they configurable? =C2=A0Are they dynamic?
What about libwebsocket? what abo= ut home grown clients?

Right now they don&= #39;t exist because the current spec doesn't have them. =C2=A0If the sp= ec were to require browsers to send timeout values that aren't actually= used, it seems likely they would send some fixed value.=C2=A0

I'm not sure that a

=C2=A0Sec-Websocket-IdleTimeout: 200

in the handshake could be described as "lots of bytes".
It will certainly be less bytes than if connection keep getting closed
due to no know idle timeouts and the client just opens then up again.

I mean collectively lots of bytes across all= the WebSocket connections until a standard exists that makes use of them. = =C2=A0Since as proposed the timeouts aren't to be used for anything, I = don't see how providing them can prevent any connections from being clo= sed.

To be clear, I am only talking about the time between w= hen they are put in the spec (now, as you are suggesting) and when they are= actually used for some purpose (some arbitrary time in the future, since y= ou appear to agree we don't want to wait and try and define how to do s= omething useful with them in the base spec).=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd56f86649072049d750947-- From jat@google.com Tue Mar 1 16:37:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5683A3A6ADF for ; Tue, 1 Mar 2011 16:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.925 X-Spam-Level: X-Spam-Status: No, score=-105.925 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8jPCstgqELG for ; Tue, 1 Mar 2011 16:37:13 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 4882C3A6A45 for ; Tue, 1 Mar 2011 16:37:12 -0800 (PST) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p220cGXZ022337 for ; Tue, 1 Mar 2011 16:38:16 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299026297; bh=AfdqgnxqjHyH3+08ZxohiD7ns3Q=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=F6WPasIWJErP3lseZMNIpJ6now96SLFJmyb9o5YvBqmTjNzgd2YC3SWAxoQEkkIE9 XzRLYvz0c0dcP7I3s86Jw== Received: from yxp4 (yxp4.prod.google.com [10.190.4.196]) by hpaq11.eem.corp.google.com with ESMTP id p220bkAq015296 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 1 Mar 2011 16:38:15 -0800 Received: by yxp4 with SMTP id 4so2730125yxp.24 for ; Tue, 01 Mar 2011 16:38:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SfHJn9IaoCesAn7YBh2UTjMv6ISvGf4BXgl5WYot2yE=; b=WuQ6sYZXz6mR13qDnJnRPckgacDfuZgXVEPSUiqkg1tBfmew0Nsc8q1KORfZEBZ0XN mv7MifQY+scULZTDH9Aw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=N92gszliYC6Qp4kybqat4n6iawQyTzI1uY6CgV2OAt34neRAd/uwTJnGkxqiJt8R8C 4T02LhYC10yxwhRgUtQw== Received: by 10.150.140.6 with SMTP id n6mr9647195ybd.160.1299026294522; Tue, 01 Mar 2011 16:38:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Tue, 1 Mar 2011 16:37:54 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> From: John Tamplin Date: Tue, 1 Mar 2011 19:37:54 -0500 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd37592d6c84b049d752012 X-System-Of-Record: true Cc: Simo.Veikkolainen@nokia.com, hybi@ietf.org, Gabriel.Montenegro@microsoft.com Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:37:15 -0000 --000e0cd37592d6c84b049d752012 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 1, 2011 at 4:39 PM, Greg Wilkins wrote: > I really don't think opcode space is going to be a problem.... it is so > hard to get agreement on even basic features, I don't see any rampant > featurism about to start soon. > Perhaps, or perhaps once we get the base spec out the door everybody will propose extensions that were deferred from the base spec. Even if they are private extensions, many of these will still need opcode space. > But I do think partitioning the opcodes is a good idea: > > frame-opcode = %x0 ; continuation frame > / %x1 ; text frame > / %x2 ; binary frame > / %x3-7 ; reserved > / frame-control-opcode > > frame-control-opcode = %x8 ; ping > / %x9 ; pong > / %xA-E ; reserved > / %xF ; close > Fragmenting the limited opcode space seems like a bad idea -- what if we don't define any new control opcodes but want to define more data opcodes or vice-versa? We will start having to have an extension opcode sooner than otherwise necessary. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd37592d6c84b049d752012 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 1, 2011 at 4:39 PM, Greg Wilkins <gregw@intalio.com> wrote:
I really don't think opcode space is going to be a pr= oblem.... it is so hard to get agreement on even basic features, I don'= t see any rampant featurism about to start soon.

Perhaps, or perhaps once we get the base spec out the door every= body will propose extensions that were deferred from the base spec. =C2=A0E= ven if they are private extensions, many of these will still need opcode sp= ace.
=C2=A0
But I do think partitionin= g the opcodes is a good idea:

frame-opcode =3D %x0 ; co= ntinuation frame
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0=C2=A0 / %x1 ; text frame
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 / %x2 ; binary frame
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 / = %x3-7 ; reserved
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 / frame-control-opcode

frame-control-opcode =3D %= x8 ; ping
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 / %x9 ; pong=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 / %xA-E ; reserved
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 / %xF ; close

Fragmenting the limited opcod= e space seems like a bad idea -- what if we don't define any new contro= l opcodes but want to define more data opcodes or vice-versa? =C2=A0We will= start having to have an extension opcode sooner than otherwise necessary.<= /div>
--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd37592d6c84b049d752012-- From gregw@intalio.com Tue Mar 1 16:37:43 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C28CC3A6BFE for ; Tue, 1 Mar 2011 16:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STGorsqLyhAE for ; Tue, 1 Mar 2011 16:37:42 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id A50373A6A45 for ; Tue, 1 Mar 2011 16:37:42 -0800 (PST) Received: by vxg33 with SMTP id 33so5303507vxg.31 for ; Tue, 01 Mar 2011 16:38:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.160.8 with SMTP id xg8mr11732278vdb.310.1299026311816; Tue, 01 Mar 2011 16:38:31 -0800 (PST) Received: by 10.52.165.129 with HTTP; Tue, 1 Mar 2011 16:38:31 -0800 (PST) In-Reply-To: <1299024081.2498.1020.camel@ds9.ducksong.com> References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> <1299024081.2498.1020.camel@ds9.ducksong.com> Date: Wed, 2 Mar 2011 11:38:31 +1100 Message-ID: From: Greg Wilkins To: "Pat McManus @Mozilla" Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:37:43 -0000 On 2 March 2011 11:01, Pat McManus @Mozilla wrote: > I'm not swayed by an argument that in 2011 an Internet protocol security > feature should be able to be disabled, and thus the attack surface > increased, in order to save the cost of a simple XOR on the data stream. > It is a bad trade off. That is not an argument that I am making - at least not in this thread or on this topic. Please see my original message at the start of this thread and I certainly did not say that we should turn off masking to save CPU. The pros/cons for masking in frame vs masking the frame are made without reference to the cost of XOR nor without reference to making masking optional. I did make the point that having masking in frame would allow intermediaries to avoid having to demask/remask. That is not turning off masking, that is just avoiding decoding/recoding when the intermediary does not care about the payload. I do happen to think that masking should be optional - but that is a separate issue to if the protocol should be flexible and consistent enough to allow it to be optional. We can have a flexible and consistent protocol and still require mandatory masking. So knocking over the argument that "we should make the protocol less secure to save the cycles of the XOR" is not relevant because nobody is making that argument. I'm sorry if my objection to your asserting that masking is cheap, regardless of it's place in the protocol stack made you think that was the argument I was making. I was simply saying that XOR is not always cheap, but it is cheaper if done on full payloads rather than on partial frames. > Greg, I don't expect you to agree. But you said that such an argument > hadn't been made - and this is the core of mine. I accept that you and others want masking to be mandatory. But I don't think that means we have to go for a design where we have no choice but to make it mandatory because it is baked into the framing. So if we go with the current consensus, that masking is mandatory, do you have any other objections to mask in frame? regards From brofield@gmail.com Tue Mar 1 16:38:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA593A6A45 for ; Tue, 1 Mar 2011 16:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzWZGglpcB5Z for ; Tue, 1 Mar 2011 16:38:33 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 0BEB93A6B5A for ; Tue, 1 Mar 2011 16:38:24 -0800 (PST) Received: by qwh6 with SMTP id 6so4616824qwh.31 for ; Tue, 01 Mar 2011 16:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sYxLtlDe+WFaOOccbl798ZoRtJLuVrbEDeJStRvcV3A=; b=TasFnWnLWa24UbKwkLPJMDA2zHAWHHwW9yKr7CVvComz40F82qakVvMWWFpwoVmugx q79WARV3EtcsGHGcMWOpYHZDWxYOgpUEALi7EAARslTsDfPFZxvWgtd6+w/cc+eQFKQ3 Pc+04EVoPLoLu4k2ejWTHUu3q5bB/lkDHCBGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=RtHc2yWbwtfHPQOBp+JXLPTMzYRkiy91e/jJ8jja1DFS8Lq1POKe5rehgrGfLEqrYm Ty29WpJGGXkXSlEZ23oGDmIgGduWkVFLY/ZpVlzIsIHlt+shWd8AvT0ofcjmI9O01dMt 7441zXstDVmg2avele9Uymw2b9zVUfGGOo/lU= MIME-Version: 1.0 Received: by 10.224.104.3 with SMTP id m3mr3192684qao.219.1299026368911; Tue, 01 Mar 2011 16:39:28 -0800 (PST) Sender: brofield@gmail.com Received: by 10.224.187.2 with HTTP; Tue, 1 Mar 2011 16:39:28 -0800 (PST) In-Reply-To: References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> Date: Wed, 2 Mar 2011 09:39:28 +0900 X-Google-Sender-Auth: zBLaa0t7ZtvjVFfCNSDzzOjypDw Message-ID: From: Brodie Thiesfield To: Greg Wilkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:38:35 -0000 On Wed, Mar 2, 2011 at 8:29 AM, Greg Wilkins wrote: > On 2 March 2011 01:37, Pat McManus @Mozilla wrote: >> >> * The mask is incredibly cheap to implement. You can do XOR at the rate >> of your memory bandwidth. The benefit to "optimizing it away" is at best >> marginal even in high bandwidth scenarios. > > That is a hand waive.=A0 It is neither incredibly cheap nor simple when > it is munged in with the framing. Surely there is no necessity to have it turned off completely. For communications where no masking is desired (whether this is wise or justified is a separate issue), just set the mask to 0. The only overhead then is 4 bytes of 0 in front of every payload and the frame format from client to server doesn't change. Of course, servers cannot force clients to use a zero or non-zero mask. That is always going to be the responsibility of the client. The client can send payload using a 0 mask anytime it wants, and if selecting mask values by random then 1/256 messages will be using it anyway. The only part of the spec that the client violates is the one that requires a random value for the mask, and that part of the spec is not checked or validated by anything. Therefore the messages are essentially valid. To avoid the receiving server from needing to examine the mask to see if it is 0 or not in order to decode the payload, define a extension that is a guarantee from the client that all mask values in this connection are going to be 0. e.g. Sec-WebSocket-Extensions: zero-mask. A server receiving and accepting this extension can skip the XOR. Note that acceptance or not of the zero-mask token can be safely ignored by the client to no detriment (i.e. just send the 0 masked messages if that is what it was intending to anyhow). Optionally a client may special case so that acceptance of the "zero-mask" token means that it sends 0 mask values, whereas non-acceptance means fully to-spec random values. Regards, Brodie From gregw@intalio.com Tue Mar 1 16:47:30 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6AE63A6A3E for ; Tue, 1 Mar 2011 16:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.712 X-Spam-Level: X-Spam-Status: No, score=-2.712 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7zEukBQB2EV for ; Tue, 1 Mar 2011 16:47:30 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id E0F163A6A30 for ; Tue, 1 Mar 2011 16:47:29 -0800 (PST) Received: by vws6 with SMTP id 6so5388993vws.31 for ; Tue, 01 Mar 2011 16:48:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.68.175 with SMTP id x15mr9681520vdt.70.1299026914010; Tue, 01 Mar 2011 16:48:34 -0800 (PST) Received: by 10.52.165.129 with HTTP; Tue, 1 Mar 2011 16:48:33 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> Date: Wed, 2 Mar 2011 11:48:33 +1100 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:47:30 -0000 On 2 March 2011 11:31, John Tamplin wrote: > If they don't actually do anything, why would anyone go change it? Currently the jetty configuration has a maxIdleTime for it's HTTP connector that is inherited by the upgraded websocket connection. There are plenty of reasons for users to tune maxIdleTIme for HTTP connections. Also, when we use websockets as a transport for cometd, we use the configuration of the interval and poll times to configure the max idle time for the connection. Users are already tuning these parameters for their environments and the websocket implementation inherits these. Besides, if you really think there is no reason to change - then we should hard code a timeout value into the spec. >> What about libwebsocket? what about home grown clients? > > Right now they don't exist because the current spec doesn't have them. = =A0If > the spec were to require browsers to send timeout values that aren't > actually used, it seems likely they would send some fixed value. If an implementation has no timeout for a connection, then I'd certainly want to know that. But I expect that most implementations do have an idle timeout, even if it is not explicitly in the spec. > I mean collectively lots of bytes across all the WebSocket connections un= til > a standard exists that makes use of them. =A0Since as proposed the timeou= ts > aren't to be used for anything, I don't see how providing them can preven= t > any connections from being closed. Well they can be used by infrastructure For example, if the browser tells me that it has a 45s idle timeout, then I'm going to raise an error if I see a cometd configuration with a poll timeout of 60s (or automatically adjust it to < 45s ). Eventually I'd like to see the protocol use ping/pongs to do this, but currently we need the frameworks (or applications )to do keep alives, and on the server side, these frameworks would have access to the client declared timeouts. > To be clear, I am only talking about the time between when they are put i= n > the spec (now, as you are suggesting) and when they are actually used for > some purpose (some arbitrary time in the future, since you appear to agre= e > we don't want to wait and try and define how to do something useful with > them in the base spec). Put them in the spec today, and cometd will start using them tomorrow. cheers From jat@google.com Tue Mar 1 16:52:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750593A6A41 for ; Tue, 1 Mar 2011 16:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.786 X-Spam-Level: X-Spam-Status: No, score=-105.786 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grMWtilya1fd for ; Tue, 1 Mar 2011 16:52:14 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 6C0143A6A21 for ; Tue, 1 Mar 2011 16:52:14 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p220rHbC028974 for ; Tue, 1 Mar 2011 16:53:18 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299027198; bh=L27Xt0PNmrZNtiRHGY5BXJO20fE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=AGULNGxOtE78lY6bjlDOyERQCeoja2EaBnaS9GC+jbS4DNmZCSNGdRIiVl6qRIT2T bB2oxdCK8iRUq8VBkPJsw== Received: from yxs7 (yxs7.prod.google.com [10.190.5.135]) by wpaz17.hot.corp.google.com with ESMTP id p220rGWD021602 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 1 Mar 2011 16:53:16 -0800 Received: by yxs7 with SMTP id 7so2194765yxs.19 for ; Tue, 01 Mar 2011 16:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BLQixa/GETWVfqrOthtnJUw1EH5M/vI/KeaCRF2Ino0=; b=BKRmvCP3C/3Z0TBH9ot0UCZuN9CwhKHdB4t6VLflGQUp3eD6lVo07TAQyGOsLWNxEw Eb9wRYRVdE69RRQSo2Uw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=c1FVhICNibsaCRit+48YlLcFtlBph6zW1JLGS8x2oSW1JMLQBky1vwC+d5xTYUyR3w GC+xthiYeJPWQteM5QSQ== Received: by 10.150.195.3 with SMTP id s3mr9743726ybf.274.1299027196187; Tue, 01 Mar 2011 16:53:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Tue, 1 Mar 2011 16:52:55 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> From: John Tamplin Date: Tue, 1 Mar 2011 19:52:55 -0500 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd48470951f2f049d7556be X-System-Of-Record: true Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:52:15 -0000 --000e0cd48470951f2f049d7556be Content-Type: text/plain; charset=UTF-8 On Tue, Mar 1, 2011 at 7:48 PM, Greg Wilkins wrote: > > To be clear, I am only talking about the time between when they are put > in > > the spec (now, as you are suggesting) and when they are actually used for > > some purpose (some arbitrary time in the future, since you appear to > agree > > we don't want to wait and try and define how to do something useful with > > them in the base spec). > > Put them in the spec today, and cometd will start using them tomorrow. > And that is a problem -- what has been proposed is agreed to be a half-baked thing just to collect data, yet here you are suggesting something will actually start using it when we haven't addressed the related issues that have been discussed on this thread. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd48470951f2f049d7556be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 1, 2011 at 7:48 PM, Greg Wilkins <gregw@intalio.com> wrote:
> To be clear, I am only talking about the time betwee= n when they are put in
> the spec (now, as you are suggesting) and when they are actually used = for
> some purpose (some arbitrary time in the future, since you appear to a= gree
> we don't want to wait and try and define how to do something usefu= l with
> them in the base spec).

Put them in the spec today, and cometd will start using them tomorrow= .

And that is a problem -- what has be= en proposed is agreed to be a half-baked thing just to collect data, yet he= re you are suggesting something will actually start using it when we haven&= #39;t addressed the related issues that have been discussed on this thread.=

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd48470951f2f049d7556be-- From gregw@intalio.com Tue Mar 1 16:55:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B5DD3A6A21 for ; Tue, 1 Mar 2011 16:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxpZBFonJz2e for ; Tue, 1 Mar 2011 16:55:21 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 883903A6A30 for ; Tue, 1 Mar 2011 16:55:21 -0800 (PST) Received: by vws6 with SMTP id 6so5394467vws.31 for ; Tue, 01 Mar 2011 16:56:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.68.175 with SMTP id x15mr9690476vdt.70.1299027385309; Tue, 01 Mar 2011 16:56:25 -0800 (PST) Received: by 10.52.165.129 with HTTP; Tue, 1 Mar 2011 16:56:25 -0800 (PST) In-Reply-To: References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> Date: Wed, 2 Mar 2011 11:56:25 +1100 Message-ID: From: Greg Wilkins To: Brodie Thiesfield Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:55:22 -0000 On 2 March 2011 11:39, Brodie Thiesfield wrote: > Surely there is no necessity to have it turned off completely. For > communications where no masking is desired (whether this is wise or > justified is a separate issue), just set the mask to 0. The only > overhead then is 4 bytes of 0 in front of every payload and the frame > format from client to server doesn't change. This is exactly what is going to happen. The Jetty Websocket test client already has a pluggable MaskGen and I have got both NullMaskGen and FixedMaskGen implementations that can be used for debugging and other testing where you just don't want the bytes to be changing randomly. I think it is unrealistic to think that other non-browser clients will not also have similar options to send zero masks. I expect that some intermediaries might use zero masks as a way to avoid remasking and that some servers will handle zero masks as special case and skip the XOR. Having an inflexible and inconsistent wire protocol will not make masking mandatory. The only way that browsers can make masking mandatory is by making sure their own implementations always use a good random generator - and that is entirely not enforceable by the protocol itself. cheers From gregw@intalio.com Tue Mar 1 17:28:46 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213C93A6C08 for ; Tue, 1 Mar 2011 17:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ5WpdkyFIL2 for ; Tue, 1 Mar 2011 17:28:45 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 45F353A6C04 for ; Tue, 1 Mar 2011 17:28:45 -0800 (PST) Received: by vxg33 with SMTP id 33so5339260vxg.31 for ; Tue, 01 Mar 2011 17:29:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.68.175 with SMTP id x15mr9730405vdt.70.1299029389178; Tue, 01 Mar 2011 17:29:49 -0800 (PST) Received: by 10.52.165.129 with HTTP; Tue, 1 Mar 2011 17:29:49 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> Date: Wed, 2 Mar 2011 12:29:49 +1100 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 01:28:46 -0000 On 2 March 2011 11:52, John Tamplin wrote: > On Tue, Mar 1, 2011 at 7:48 PM, Greg Wilkins wrote: >> Put them in the spec today, and cometd will start using them tomorrow. > > And that is a problem -- what has been proposed is agreed to be a half-baked > thing just to collect data, yet here you are suggesting something will > actually start using it when we haven't addressed the related issues that > have been discussed on this thread. No that is not what I'm saying. So I never said that declaring timeouts is half baked. It is valuable meta information that can be used today. Declaring that the protocol MUST send ping/pongs at that rate would be half baked. It is probably too hard for us to achieve consensus for a keep alive mechanism in the protocol itself, but that declared timeouts would be a good first step towards a standard keep alive mechanism. Failing a standard keep alive mechanism, frameworks and applications will have to implement their own keep alives - websocket applications will just not work without them! Declaring that a problem is too hard for us to solve, does not make the problem go away, so there will be regular keep-alive-like messages sent no matter what we do in the specification. If we provide a standard way for timeouts to be declared, then at least on the server side, that information can be used to guide the frameworks and applications in choosing a frequency (which may still prove to be wrong due to intermediaries, but that is valuable information to know and at least the framework could start any backoff strategy at a realistic timeout). If you are really worried about the bytes - then we could define control packets to query configuration parameters, but that sounds like a lot more faff than just Sec-WebSocket-IdleTimeout: 200s cheers From jat@google.com Tue Mar 1 17:36:11 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73BFE3A6A30 for ; Tue, 1 Mar 2011 17:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.927 X-Spam-Level: X-Spam-Status: No, score=-105.927 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8ECZcejGicF for ; Tue, 1 Mar 2011 17:36:10 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B980C3A6AC3 for ; Tue, 1 Mar 2011 17:36:09 -0800 (PST) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p221bDKC021680 for ; Tue, 1 Mar 2011 17:37:13 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299029833; bh=kkVYNwuIfYdCOVg9Yu4xZJG8MCk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Z8CyDwGKVxwMtlsQMlYPzCCwbcO6E9sCD61bpSw/yL3WhSOmvxUG94WGxelksMXbA XMKBwIye6ddg6aC/Cwl/A== Received: from yia25 (yia25.prod.google.com [10.243.65.25]) by kpbe20.cbf.corp.google.com with ESMTP id p221a93V014050 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 1 Mar 2011 17:37:12 -0800 Received: by yia25 with SMTP id 25so3027629yia.7 for ; Tue, 01 Mar 2011 17:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1c9KvtXGNyhYqGfcmyClxsUTnw2LP5sakfnIL3f5fIs=; b=JC03CnZY9ROX0NP1n94H17ga2vPL0CCw1NnB+XIBh6b68e7xR3RX8ee62nR9+/YMd8 WCrgp77l7AeSxRxUCXbQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=PBO2AxGsYch79StMCJt88LTtgLJus8Y9oZGV20mtvrWfgOVUf//R2XuSozMs4MCvjX Tphbdnwh+8nX73a0N75w== Received: by 10.150.195.3 with SMTP id s3mr9785787ybf.274.1299029832155; Tue, 01 Mar 2011 17:37:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Tue, 1 Mar 2011 17:36:52 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> From: John Tamplin Date: Tue, 1 Mar 2011 20:36:52 -0500 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd48470b2c551049d75f3f3 X-System-Of-Record: true Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 01:36:11 -0000 --000e0cd48470b2c551049d75f3f3 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 1, 2011 at 8:29 PM, Greg Wilkins wrote: > Failing a standard keep alive mechanism, frameworks and applications > will have to implement their own keep alives - websocket applications > will just not work without them! Declaring that a problem is too > hard for us to solve, does not make the problem go away, so there will > be regular keep-alive-like messages sent no matter what we do in the > specification. > And I am suggesting that applications, which as you agree must have them, must implement them without use of the information you would propose to add in the handshake because it is not exposed to them and wouldn't actually trigger either keepalives or automatic timeouts of the connection. Therefore, providing the information in the handshake, which applications then ignore and build their own, seems pointless. Anyway, I think we have both said our points and I don't think we are changing each others' mind. My preference remains to leave it out of the spec until it can be defined in such a way to actually be used for the intended purpose, rather than just having it there just to be there. If others think it is useful to have it now, then fine. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd48470b2c551049d75f3f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 1, 2011 at 8:29 PM, Greg Wilkins <gregw@intalio.com> wrote:
Failing a standard keep alive mechanism, frameworks and a= pplications
will have to implement their own keep alives - websocket applications
will just not work without them! =C2=A0 =C2=A0Declaring that a problem is t= oo
hard for us to solve, does not make the problem go away, so there will
be regular keep-alive-like messages sent no matter what we do in the
specification.

And I am suggesting that= applications, which as you agree must have them, must implement them witho= ut use of the information you would propose to add in the handshake because= it is not exposed to them and wouldn't actually trigger either keepali= ves or automatic timeouts of the connection. =C2=A0Therefore, providing the= information in the handshake, which applications then ignore and build the= ir own, seems pointless.

Anyway, I think we have both said our points and I don&= #39;t think we are changing each others' mind. =C2=A0My preference rema= ins to leave it out of the spec until it can be defined in such a way to ac= tually be used for the intended purpose, rather than just having it there j= ust to be there. =C2=A0If others think it is useful to have it now, then fi= ne.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd48470b2c551049d75f3f3-- From gregw@intalio.com Tue Mar 1 17:44:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCF923A6A30 for ; Tue, 1 Mar 2011 17:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULmvrU88TNWv for ; Tue, 1 Mar 2011 17:44:22 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 36A0F3A6A21 for ; Tue, 1 Mar 2011 17:44:21 -0800 (PST) Received: by vxg33 with SMTP id 33so5350801vxg.31 for ; Tue, 01 Mar 2011 17:45:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.167.166 with SMTP id zp6mr12471728vdb.150.1299030325342; Tue, 01 Mar 2011 17:45:25 -0800 (PST) Received: by 10.52.165.129 with HTTP; Tue, 1 Mar 2011 17:45:25 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> Date: Wed, 2 Mar 2011 12:45:25 +1100 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 01:44:22 -0000 On 2 March 2011 12:36, John Tamplin wrote: > And I am suggesting that applications, which as you agree must have them, > must implement them without use of the information you would propose to add > in the handshake because it is not exposed to them and wouldn't actually > trigger either keepalives or automatic timeouts of the connection. Why is this information not available on the server? There is no standardised API there that would need to be changed and the current suggestion is to send this information as a simple HTTP header, which will very likely be available to at least the framework. > Anyway, I think we have both said our points and I don't think we are > changing each others' mind. However, I do think we are understanding each other minds better and also I think there are some assumption (eg above) that may not be valid and may influence your (and others) mind. cheers From mcmanus@ducksong.com Tue Mar 1 20:01:18 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A0A3A6C14 for ; Tue, 1 Mar 2011 20:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCEFifbh--fb for ; Tue, 1 Mar 2011 20:01:17 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 37C633A6B5C for ; Tue, 1 Mar 2011 20:01:17 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id 97AE810442; Tue, 1 Mar 2011 23:02:21 -0500 (EST) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 2338E101F6; Tue, 1 Mar 2011 23:02:16 -0500 (EST) From: "Pat McManus @Mozilla" To: Greg Wilkins In-Reply-To: References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> <1299024081.2498.1020.camel@ds9.ducksong.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Mar 2011 23:01:52 -0500 Message-ID: <1299038512.2498.1270.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 04:01:18 -0000 On Wed, 2011-03-02 at 11:38 +1100, Greg Wilkins wrote: > So if we go with the current consensus, that masking is mandatory, do > you have any other objections to mask in frame? > Hi Greg, in my opinion, it is more of the same: a micro optimization that trades away the property of a full stream mask in return for not very much of real use. I think -06 has this right. From neonux@gmail.com Tue Mar 1 20:27:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099A83A6A30 for ; Tue, 1 Mar 2011 20:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-dBj2BZJ2Dt for ; Tue, 1 Mar 2011 20:27:24 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 834C83A67ED for ; Tue, 1 Mar 2011 20:27:24 -0800 (PST) Received: by wwb22 with SMTP id 22so3954157wwb.13 for ; Tue, 01 Mar 2011 20:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=0uwCab+aDJDGwyHnkapYmMSFJeGH7zONPsH6d6CT6DM=; b=cNoKBggrAe20OPLGOvLneRGv4BBvzBBR6+NO/mSu4qByarv8X+16CaWpAe5W+HVMSW Rl9ZR7AEoD5TrHYex17cPbvDpFBI5VxoGb3BvU8gSB7jPBJyHdjglZWDjMOKVaCX65m+ gpmUhmKJgSxqt7MwXxweztcmfpiMXGUzC97ZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=i+XvZYJRQuyzjJ3YU8T9U9jnoV3v5qP6wMwN3gDRY0ZnUUaZea0mOPGqEFlHbkvqQw uFQ5SNpbH2ZdbpNybaBJWP4t1jMaBm7sSKgp4nmSptJgrfejL04q98rpC0L/hRJQYNfi QIhqs3JLtFOOXeV0bsIac4aXLz+0h4MdZMmT4= Received: by 10.227.9.74 with SMTP id k10mr6918087wbk.204.1299040108069; Tue, 01 Mar 2011 20:28:28 -0800 (PST) MIME-Version: 1.0 Sender: neonux@gmail.com Received: by 10.227.55.14 with HTTP; Tue, 1 Mar 2011 20:27:57 -0800 (PST) In-Reply-To: <1298990267.2498.668.camel@ds9.ducksong.com> References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> From: Cedric Vivier Date: Wed, 2 Mar 2011 12:27:57 +0800 X-Google-Sender-Auth: WZ8jvRl_SKQoy9gTtjpdsUFUwfA Message-ID: To: "Pat McManus @Mozilla" Content-Type: text/plain; charset=UTF-8 Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 04:27:26 -0000 On Tue, Mar 1, 2011 at 22:37, Pat McManus @Mozilla wrote: > * The mask is incredibly cheap to implement. You can do XOR at the rate > of your memory bandwidth. The benefit to "optimizing it away" is at best > marginal even in high bandwidth scenarios. Agreed, XOR performance is not an issue. On the other hand scalability is, and having to XOR the full stream means it is not possible anymore to use scalable kernel zero-copy mechanisms to pass data from one point to another without having to context switch on every message. With that in mind, I assume the scalability cost of full stream XOR might be quite significant, especially when it comes to WebSocket multiplexers (ie. dispatching each particular websocket message to a specific worker to process it) which otherwise would not do anything but pass data around with no copy nor context switch. Regards, From gregw@intalio.com Tue Mar 1 21:23:41 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB403A6A30 for ; Tue, 1 Mar 2011 21:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRORAWnl4SgM for ; Tue, 1 Mar 2011 21:23:39 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 7F69F3A67D2 for ; Tue, 1 Mar 2011 21:23:07 -0800 (PST) Received: by vws6 with SMTP id 6so5554195vws.31 for ; Tue, 01 Mar 2011 21:24:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.97.130 with SMTP id ea2mr5785656vdb.230.1299043451970; Tue, 01 Mar 2011 21:24:11 -0800 (PST) Received: by 10.52.165.129 with HTTP; Tue, 1 Mar 2011 21:24:11 -0800 (PST) In-Reply-To: References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> Date: Wed, 2 Mar 2011 16:24:11 +1100 Message-ID: From: Greg Wilkins To: Cedric Vivier Content-Type: multipart/alternative; boundary=20cf307cfc7880a51a049d791fb1 Cc: Hybi Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 05:23:41 -0000 --20cf307cfc7880a51a049d791fb1 Content-Type: text/plain; charset=ISO-8859-1 On 2 March 2011 15:27, Cedric Vivier wrote: > On Tue, Mar 1, 2011 at 22:37, Pat McManus @Mozilla wrote: >> * The mask is incredibly cheap to implement. You can do XOR at the rate >> of your memory bandwidth. The benefit to "optimizing it away" is at best >> marginal even in high bandwidth scenarios. > > Agreed, XOR performance is not an issue. > On the other hand scalability is, and having to XOR the full stream > means it is not possible anymore to use scalable kernel zero-copy > mechanisms to pass data from one point to another without having to > context switch on every message. > > With that in mind, I assume the scalability cost of full stream XOR > might be quite significant, especially when it comes to WebSocket > multiplexers (ie. dispatching each particular websocket message to a > specific worker to process it) which otherwise would not do anything > but pass data around with no copy nor context switch. ... and just to divert this thread back to the topic and avoid another round of debating how expensive XOR is or isn't.... the whole point of this proposal is that things like multiplexers don't care about the payload, but do care about framing and extension data. So if we have masking in frame as an extension, then a multiplexer will be able to take a masked payload, prepend some channel meta data and send in a new frame, but without unmasking and remasking: Client1->84L1M1M1M1M1P1..P1 \ MUX-> 84L?C1C1M1M1M1M1P1..P184L?C2C2M2M2M2M2P2..P2->server / Client2->84L2M2M2M2M2P2...P2 L? length M? mask C? mux channel P? payload If we can do it this way, then the whole conversation about is XOR too expensive for intermediaries goes away, because the intermediary does not need to de-mask and re-mask. Note that this needs masking to be an extension, so that we can negotiate to apply it after the MUX extension, otherwise the MUX channel data would need to be masked and we would need to de-mask and re-mask. Note also that having masking an extension does not mean it does not have to be mandatory. We can still insist that it is present in all negotiated extension orderings if we want. cheers --20cf307cfc7880a51a049d791fb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2 March 2011 15:27, Cedric Vivier <cedricv@neonux.com> wrote:
> On Tue, Mar 1, 2011 a= t 22:37, Pat McManus @Mozilla <m= cmanus@ducksong.com> wrote:
>> * The mask is incredibly cheap to implement. You can do XOR at the= rate
>> of your memory bandwidth. The benefit to "optimizing= it away" is at best
>> marginal even in high bandwidth scena= rios.
>
> Agreed, XOR performance is not an issue.
> On the other = hand scalability is, and having to XOR the full stream
> means it is = not possible anymore to use scalable kernel zero-copy
> mechanisms to= pass data from one point to another without having to
> context switch on every message.
>
> With that in mind, I = assume the scalability cost of full stream XOR
> might be quite signi= ficant, especially when it comes to WebSocket
> multiplexers (ie. dis= patching each particular websocket message to a
> specific worker to process it) which otherwise would not do anything> but pass data around with no copy nor context switch.


...= and just to divert this thread back to the topic and avoid another round o= f debating how expensive XOR is or isn't....

the whole point of this proposal is that things like multiplexers don&#= 39;t care about the payload, but do care about framing and extension data. = =A0 So if we have masking in frame as an extension, then a multiplexer will= be able to take a masked payload, prepend some channel meta data and send = in a new frame, but without unmasking and remasking:


Client1->84L= 1M1M1M1M1P1..P1
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0 =A0=A0 MUX-> 84L?C1C1M1M1M1M1P1..= P184L?C2C2M2M2M2M2P2..P2->server
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 / Client2->84L2M2M2M2M= 2P2...P2


L?=A0 length
M? mask
C? mux channel
P? = payload

If we can do it this way, then the whole conversation about = is XOR too expensive for intermediaries goes away, because the intermediary= does not need to de-mask and re-mask.

Note that this needs masking to be an extension, so that we can negotia= te to apply it after the MUX extension, otherwise the MUX channel data woul= d need to be masked and we would need to de-mask and re-mask.

Note a= lso that having masking an extension does not mean it does not have to be m= andatory. We can still insist that it is present in all negotiated extensio= n orderings if we want.

cheers




--20cf307cfc7880a51a049d791fb1-- From jat@google.com Tue Mar 1 21:34:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E243A698D for ; Tue, 1 Mar 2011 21:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.793 X-Spam-Level: X-Spam-Status: No, score=-105.793 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRi1SJ05L0Fr for ; Tue, 1 Mar 2011 21:34:24 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 5FCA53A694A for ; Tue, 1 Mar 2011 21:34:22 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p225ZQ0E031221 for ; Tue, 1 Mar 2011 21:35:27 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299044127; bh=A7AqYxkPrZqCLKfV8Wbh/GXfcWE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=PIgrpX8ELQGgFRTJml75uID6pIignR9Wce4JbRbOIQS69LgxFOzdPlGHMKDZwcThj FuyiCRWK3FsnySN9GiTfQ== Received: from gwaa12 (gwaa12.prod.google.com [10.200.27.12]) by wpaz29.hot.corp.google.com with ESMTP id p225ZPZe008941 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 1 Mar 2011 21:35:25 -0800 Received: by gwaa12 with SMTP id a12so3108810gwa.18 for ; Tue, 01 Mar 2011 21:35:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/vi5K5593ySfk72I4w/l0/axOKwal8e4PTCQuLJVDDU=; b=jsatwJ/1ztWA6TucweEkZ77r6zV84maFF2qUDWG8qYZ+JVLcf5Tnil7i5dxDjGYL6L x+xKyeaVx2cuvAU2/qBw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Nf5PkLmwJkaYxZWaApWRDUEx+/MdNL4vzCT3SB4cJUng9opa7xF9RX241TWYNdL7Oh Z/+uWnY2J4U9BMsXltMw== Received: by 10.150.198.11 with SMTP id v11mr9917915ybf.388.1299044125125; Tue, 01 Mar 2011 21:35:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Tue, 1 Mar 2011 21:35:05 -0800 (PST) In-Reply-To: References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> From: John Tamplin Date: Wed, 2 Mar 2011 00:35:05 -0500 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd34888a02c57049d79477c X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 05:34:26 -0000 --000e0cd34888a02c57049d79477c Content-Type: text/plain; charset=UTF-8 On Wed, Mar 2, 2011 at 12:24 AM, Greg Wilkins wrote: > the whole point of this proposal is that things like multiplexers don't > care about the payload, but do care about framing and extension data. So > if we have masking in frame as an extension, then a multiplexer will be able > to take a masked payload, prepend some channel meta data and send in a new > frame, but without unmasking and remasking: > > > Client1->84L1M1M1M1M1P1..P1 > \ > MUX-> > 84L?C1C1M1M1M1M1P1..P184L?C2C2M2M2M2M2P2..P2->server > / > Client2->84L2M2M2M2M2P2...P2 > > > L? length > M? mask > C? mux channel > P? payload > > If we can do it this way, then the whole conversation about is XOR too > expensive for intermediaries goes away, because the intermediary does not > need to de-mask and re-mask. > > Note that this needs masking to be an extension, so that we can negotiate > to apply it after the MUX extension, otherwise the MUX channel data would > need to be masked and we would need to de-mask and re-mask. > > Note also that having masking an extension does not mean it does not have > to be mandatory. We can still insist that it is present in all negotiated > extension orderings if we want. > I think when you start saying that extension data is not masked, that is a very slippery slope and various people have already discussed that we do not want to allow extension data to be unmasked. I would instead think that client->server MUX traffic would be entirely masked, in which case you would have to do some modification of the payloads anyway if you are aggregating multiple logical channels (if only one channels contents is included you can simply use the same key). I would suggest something like: MUX_OPCODE COMBINED_LEN MASK_KEY Mask(MASK_KEY,"Channel1 [unmasked channel1 frame] Channel2 [unmasked channel2 frame]") and you could be clever and as you are copying the logical channel frames you XOR them with (CHANNEL1_MASK ^ MASK_KEY) and (CHANNEL2_MASK ^ MASK_KEY) as appropriate. Also, I expect the initial uses of a MUX extension is for a browser to aggregate connections to a single server, in which case there is no unmask/remask involved -- you simply build the MUX frame directly from the source data. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd34888a02c57049d79477c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 2, 2011 at 12:24 AM, Greg Wilkins <gregw@intalio.com<= /a>> wrote:
the whole point of this proposal is that things like mult= iplexers don't care about the payload, but do care about framing and ex= tension data. =C2=A0 So if we have masking in frame as an extension, then a= multiplexer will be able to take a masked payload, prepend some channel me= ta data and send in a new frame, but without unmasking and remasking:


Client1->84L1M= 1M1M1M1P1..P1
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 MUX-> 84L?C1C1M1M1M1M1P1..P184L?C2C2M2M2M= 2M2P2..P2->server
= =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /
Client2->84L2M2M2M2M2P= 2...P2


L?=C2=A0 length
M? mask
C? mux channel
P?= payload

If we can do it this way, then the whole conversation about= is XOR too expensive for intermediaries goes away, because the intermediar= y does not need to de-mask and re-mask.

Note that this needs masking to be an extension, so that we can negotia= te to apply it after the MUX extension, otherwise the MUX channel data woul= d need to be masked and we would need to de-mask and re-mask.

Note a= lso that having masking an extension does not mean it does not have to be m= andatory. We can still insist that it is present in all negotiated extensio= n orderings if we want.

I think when you start saying that extensi= on data is not masked, that is a very slippery slope and various people hav= e already discussed that we do not want to allow extension data to be unmas= ked. =C2=A0I would instead think that client->server MUX traffic would b= e entirely masked, in which case you would have to do some modification of = the payloads anyway if you are aggregating multiple logical channels (if on= ly one channels contents is included you can simply use the same key).

I would suggest something like:

MUX_OPCODE COMBINED_LEN MASK_KEY Mask(MASK_KEY,"Channel1 [unmasked c= hannel1 frame] Channel2 [unmasked channel2 frame]")

and you could be clever and as you are copying the logical chann= el frames you XOR them with (CHANNEL1_MASK ^ MASK_KEY) and (CHANNEL2_MASK ^= MASK_KEY) as appropriate.


--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd34888a02c57049d79477c-- From gregw@intalio.com Tue Mar 1 21:53:37 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97E593A6933 for ; Tue, 1 Mar 2011 21:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0CJoi3l1B0u for ; Tue, 1 Mar 2011 21:53:36 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 6B25F3A67D2 for ; Tue, 1 Mar 2011 21:53:36 -0800 (PST) Received: by vxg33 with SMTP id 33so5487563vxg.31 for ; Tue, 01 Mar 2011 21:54:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.167.166 with SMTP id zp6mr12737368vdb.150.1299045281015; Tue, 01 Mar 2011 21:54:41 -0800 (PST) Received: by 10.52.165.129 with HTTP; Tue, 1 Mar 2011 21:54:40 -0800 (PST) In-Reply-To: References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> Date: Wed, 2 Mar 2011 16:54:40 +1100 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: multipart/alternative; boundary=bcaec53f8eaf85a721049d798c82 Cc: Hybi Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 05:53:37 -0000 --bcaec53f8eaf85a721049d798c82 Content-Type: text/plain; charset=ISO-8859-1 On 2 March 2011 16:35, John Tamplin wrote: > > I think when you start saying that extension data is not masked, that is a > very slippery slope and various people have already discussed that we do not > want to allow extension data to be unmasked. > I would expect that from a browser, masking would always be mandatory and always the first extension. So all extension data from a browser would be masked. > I would instead think that client->server MUX traffic would be entirely > masked, in which case you would have to do some modification of the payloads > anyway if you are aggregating multiple logical channels (if only one > channels contents is included you can simply use the same key) > If intermediaries are involved and they want to be clever with the mask key, they will just set it to zero. It is a fallacy to pretend that it can't be turn off. > I would suggest something like: > > MUX_OPCODE COMBINED_LEN MASK_KEY Mask(MASK_KEY,"Channel1 [unmasked channel1 > frame] Channel2 [unmasked channel2 frame]") > That looks like you are combining two frames from different clients into a single frame. I'm not sure why we would do that. I expect a MUX channel to keep separate frames separate and merely tag them with some extension data to identify the channel. But then I guess they can keep the same mask key, so perhaps my concern here is over stated. But I still believe the arguments for symmetry, simplicity and flexibility hold. and you could be clever and as you are copying the logical channel frames > you XOR them with (CHANNEL1_MASK ^ MASK_KEY) and (CHANNEL2_MASK ^ MASK_KEY) > as appropriate. > That only works if you copy data with a for loops 1 byte at a time. Most scalable applications avoid doing that and instead use fast array copy mechanisms that get delegated to hardware rather than software loops. But I do concede that XOR is not expensive - but the cost of XOR is not the primary argument for masking in frame. > Also, I expect the initial uses of a MUX extension is for a browser to > aggregate connections to a single server, in which case there is no > unmask/remask involved -- you simply build the MUX frame directly from the > source data. > And browser can still mandate that masking is the first extension and thus mask all MUX data. I am just fearful anytime I see an argument that there is only 1 true way to achieve something and that it is OK to have a special case because we know how it will be used etc. etc. We need flexibility and agility to adapt to differing circumstances. We certainly don't want a system were we start forcing intermediaries to game the mask keys to achieve scalability. cheers --bcaec53f8eaf85a721049d798c82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2 March 2011 16:35, John Tamplin <jat@google.com><= /span> wrote:
I think when you start saying that extensio= n data is not masked, that is a very slippery slope and various people have= already discussed that we do not want to allow extension data to be unmask= ed.

I would expect that from a browser, masking wou= ld always be mandatory and always the first extension.=A0 So all extension = data from a browser would be masked.

=A0
=A0I would instead think that client->se= rver MUX traffic would be entirely masked, in which case you would have to = do some modification of the payloads anyway if you are aggregating multiple= logical channels (if only one channels contents is included you can simply= use the same key)

If intermediaries are involved and they want to= be clever with the mask key, they will just set it to zero.=A0=A0 It is a = fallacy to pretend that it can't be turn off.

=A0
I would suggest something like:

MUX_OPCODE CO= MBINED_LEN MASK_KEY Mask(MASK_KEY,"Channel1 [unmasked channel1 frame] = Channel2 [unmasked channel2 frame]")

That looks like you are combining two frames from different clients int= o a single frame.=A0 I'm not sure why we would do that.=A0 I expect a M= UX channel to keep separate frames separate and merely tag them with some e= xtension data to identify the channel.=A0 But then I guess they can keep th= e same mask key, so perhaps my concern here is over stated.=A0=A0 But I sti= ll believe the arguments for symmetry, simplicity and flexibility hold.

and you could be clever and as you are copying the= logical channel frames you XOR them with (CHANNEL1_MASK ^ MASK_KEY) and (C= HANNEL2_MASK ^ MASK_KEY) as appropriate.

That only works if you copy data with a for loo= ps 1 byte at a time.=A0 Most scalable applications avoid doing that and ins= tead use fast array copy mechanisms that get delegated to hardware rather t= han software loops.=A0=A0 But I do concede that XOR is not expensive=A0 - b= ut the cost of XOR is not the primary argument for masking in frame.

=A0
Also, I expect the initial uses of a MUX extension is for a browser to agg= regate connections to a single server, in which case there is no unmask/rem= ask involved -- you simply build the MUX frame directly from the source dat= a.

And browser can still mandate that masking is the fir= st extension and thus mask all MUX data.

I am just fearf= ul anytime I see an argument that there is only 1 true way to achieve somet= hing and that it is OK to have a special case because we know how it will b= e used etc. etc. =A0 We need flexibility and agility to adapt to differing = circumstances.=A0 We certainly don't want a system were we start forcin= g intermediaries to game the mask keys to achieve scalability.


cheers



=A0
--bcaec53f8eaf85a721049d798c82-- From jat@google.com Tue Mar 1 22:24:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 766493A6A83 for ; Tue, 1 Mar 2011 22:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.929 X-Spam-Level: X-Spam-Status: No, score=-105.929 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuFR+zg8Fxrw for ; Tue, 1 Mar 2011 22:24:34 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 0F1D73A6A8F for ; Tue, 1 Mar 2011 22:24:32 -0800 (PST) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p226Pa0Y007097 for ; Tue, 1 Mar 2011 22:25:37 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299047137; bh=//j1oVbxAQm7DtT5NoT0dZ0anKw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=LpVqsgNveLL273BAZ7SgujBVFup4yr9xwJGQ/4j+dxVTZNErlnZw0qZnT9e7xeU1y Oq81DnCBto51DpkFj+naQ== Received: from gxk2 (gxk2.prod.google.com [10.202.11.2]) by kpbe18.cbf.corp.google.com with ESMTP id p226PZdN014245 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 1 Mar 2011 22:25:35 -0800 Received: by gxk2 with SMTP id 2so2485739gxk.28 for ; Tue, 01 Mar 2011 22:25:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7d1kDteNZnz/hxhgoCNSntdF846rfSTtntf3POO/Rc0=; b=fXLH7EnM+Jv7k0ZiY5RLsbzJNYGAGqiJf6wtgk8tQWKHcQV0WJeSNS5iF9hqKcOjJT URHvZhP3w33I7CHhhbFw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=NPlKdbzHXusdMIyZZU7zoijg/YUSK30FlToX6nC8Ic7YOyPgv/iRZBRx0/CfQXtPW+ KV0S2T7jkzvD4t5h8yKQ== Received: by 10.150.140.6 with SMTP id n6mr9959719ybd.160.1299047135115; Tue, 01 Mar 2011 22:25:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Tue, 1 Mar 2011 22:25:15 -0800 (PST) In-Reply-To: References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> From: John Tamplin Date: Wed, 2 Mar 2011 01:25:15 -0500 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd3759208febc049d79fbc3 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 06:24:39 -0000 --000e0cd3759208febc049d79fbc3 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 2, 2011 at 12:54 AM, Greg Wilkins wrote: > I would instead think that client->server MUX traffic would be entirely >> masked, in which case you would have to do some modification of the payloads >> anyway if you are aggregating multiple logical channels (if only one >> channels contents is included you can simply use the same key) >> > > If intermediaries are involved and they want to be clever with the mask > key, they will just set it to zero. It is a fallacy to pretend that it > can't be turn off. > And then they would have to unmask the client frames, which is what I thought you were trying to avoid? > MUX_OPCODE COMBINED_LEN MASK_KEY Mask(MASK_KEY,"Channel1 [unmasked channel1 >> frame] Channel2 [unmasked channel2 frame]") >> > > That looks like you are combining two frames from different clients into a > single frame. I'm not sure why we would do that. I expect a MUX channel to > keep separate frames separate and merely tag them with some extension data > to identify the channel. But then I guess they can keep the same mask key, > so perhaps my concern here is over stated. But I still believe the > arguments for symmetry, simplicity and flexibility hold. > Right, if there is only one logical frame inside the MUXed frame you don't have to remask anything anyway, so I assumed the discussion was about when you had more than one. As for why you might want more than one, think about the way people use browsers now. You probably have a number of tabs open, and a number of long-running AJAX apps in some of them. Those apps periodically make connections back to the server to check for new mail, poll for messages, send user keystrokes, etc. The server would certainly prefer to have one connection for all those apps in all those tabs (and you may have modular apps such that one tab may have multiple connections). If many of these messages are small, network utilization would be much better if the small messages were aggregated into one larger message (of course there is a latency trade-off here). Likewise, intermediaries for bandwidth-constrained networks (such as VPN crossing the public internet or perhaps some mobile network configurations) will also have interest in aggregating small frames. > I am just fearful anytime I see an argument that there is only 1 true way > to achieve something and that it is OK to have a special case because we > know how it will be used etc. etc. We need flexibility and agility to > adapt to differing circumstances. We certainly don't want a system were we > start forcing intermediaries to game the mask keys to achieve scalability. > I think it is going to be hard to convince browser vendors that some part of the frame, including extension data that hasn't been invented yet, is safe to leave unmasked. I think it is feasible to have the option available and have browsers enforce it the way they want it, but that idea doesn't seem to be getting much traction. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd3759208febc049d79fbc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 2, 2011 at 12:54 AM, Greg Wilkins <gregw@intalio.com<= /a>> wrote:
=C2=A0I would instead= think that client->server MUX traffic would be entirely masked, in whic= h case you would have to do some modification of the payloads anyway if you= are aggregating multiple logical channels (if only one channels contents i= s included you can simply use the same key)

If intermediaries are involved and they w= ant to be clever with the mask key, they will just set it to zero.=C2=A0=C2= =A0 It is a fallacy to pretend that it can't be turn off.

And then they would have to unmask the client frames, w= hich is what I thought you were trying to avoid?
=C2=A0
MUX_OPCODE COMBINED_L= EN MASK_KEY Mask(MASK_KEY,"Channel1 [unmasked channel1 frame] Channel2= [unmasked channel2 frame]")

That looks like you are combining two frames from different clients int= o a single frame.=C2=A0 I'm not sure why we would do that.=C2=A0 I expe= ct a MUX channel to keep separate frames separate and merely tag them with = some extension data to identify the channel.=C2=A0 But then I guess they ca= n keep the same mask key, so perhaps my concern here is over stated.=C2=A0= =C2=A0 But I still believe the arguments for symmetry, simplicity and flexi= bility hold.

Right, if there is only one lo= gical frame inside the MUXed frame you don't have to remask anything an= yway, so I assumed the discussion was about when you had more than one.

As for why you might want more than one, think about th= e way people use browsers now. =C2=A0You probably have a number of tabs ope= n, and a number of long-running AJAX apps in some of them. =C2=A0Those apps= periodically make connections back to the server to check for new mail, po= ll for messages, send user keystrokes, etc. =C2=A0The server would certainl= y prefer to have one connection for all those apps in all those tabs (and y= ou may have modular apps such that one tab may have multiple connections). = =C2=A0If many of these messages are small, network utilization would be muc= h better if the small messages were aggregated into one larger message (of = course there is a latency trade-off here). =C2=A0Likewise, intermediaries f= or bandwidth-constrained networks (such as VPN crossing the public internet= or perhaps some mobile network=C2=A0configurations) will also have interes= t in aggregating small frames.
=C2=A0
I am just fea= rful anytime I see an argument that there is only 1 true way to achieve som= ething and that it is OK to have a special case because we know how it will= be used etc. etc. =C2=A0 We need flexibility and agility to adapt to diffe= ring circumstances.=C2=A0 We certainly don't want a system were we star= t forcing intermediaries to game the mask keys to achieve scalability.

I think it is going to b= e hard to convince browser vendors that some part of the frame, including e= xtension data that hasn't been invented yet, is safe to leave unmasked.= =C2=A0I think it is feasible to have the option available and have browser= s enforce it the way they want it, but that idea doesn't seem to be get= ting much traction.=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd3759208febc049d79fbc3-- From gregw@intalio.com Tue Mar 1 23:04:40 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666243A6C2C for ; Tue, 1 Mar 2011 23:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.716 X-Spam-Level: X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JA-AhGeLbN7Z for ; Tue, 1 Mar 2011 23:04:37 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 844023A6C25 for ; Tue, 1 Mar 2011 23:04:37 -0800 (PST) Received: by vws6 with SMTP id 6so5598342vws.31 for ; Tue, 01 Mar 2011 23:05:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.98.132 with SMTP id ei4mr343364vdb.190.1299049542325; Tue, 01 Mar 2011 23:05:42 -0800 (PST) Received: by 10.52.165.129 with HTTP; Tue, 1 Mar 2011 23:05:42 -0800 (PST) In-Reply-To: References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> Date: Wed, 2 Mar 2011 18:05:42 +1100 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 07:04:40 -0000 On 2 March 2011 17:25, John Tamplin wrote: > And then they would have to unmask the client frames, which is what I tho= ught you were trying to avoid I=A0 was responding to your example where MUX is done in browser and there is no intermediary.=A0=A0 I'm concerned about intermediaries having to demask just to know where the framing boundaries are - and not just (or even) because of performance. If browser are doing the muxing, then there is not an issue.=A0=A0=A0=A0 Of course it is still possible for an intermediary to the MUX the already MUXed connection from the browser, in which case it would be desirable for it to not have to demask the frames in order to do it's work. > Right, if there is only one logical frame inside the MUXed frame you don'= t have to remask anything anyway, so I assumed the discussion was about whe= n you had more than one. Well even with 1, the intermediary has to demask=A0 because the frame is ma= sked. OK, it does not need to demask=A0 the entire frame and it can reuse the mask on the outbound connection so it can just copy over the payload after the variable length length fields..... but that is really rather ugly and a real violation of layered protocols.=A0 Essentially the intermediaries are gaming the mask algorithm. > As for why you might want more than one, think about the way people use b= rowsers now. =A0You probably have a number of tabs open, and a number of lo= ng-running AJAX apps in some of them. =A0Those apps periodically make conne= ctions back to the server to check for new mail, poll for messages, send us= er keystrokes, etc. =A0The server would certainly prefer to have one connec= tion for all those apps in all those tabs (and you may have modular apps su= ch that one tab may have multiple connections). =A0If many of these message= s are small, network utilization would be much better if the small messages= were aggregated into one larger message (of course there is a latency trad= e-off here). Really? will the network really care if the TCP/IP packet contains 1 aggregate WS frame or several individual frames? > I think it is going to be hard to convince browser vendors that some part= of the frame, including extension data that hasn't been invented yet, is s= afe to leave unmasked. =A0I think it is feasible to have the option availab= le and have browsers enforce it the way they want it, I'm not trying to convince browser vendors to include extension data that is either unmasked or not invented yet. Browser vendors are free to insist that masking is the mandatory first extension using a good mask generator - so all data is masked and that is not optional. I don't think we should be running scared about what browser vendors may or may not accept. They have expressed requirements that they want mandatory masking and I think my proposal allows them to have that. > but that idea doesn't seem to be getting much traction. I have seen several voices in support. The voices in opposition appear to have miss understood the proposal and are saying that they want mandatory masking (which can be done) or that XOR is cheap (which it mostly is and this proposal is not motivated by the expense of masking). cheers From salvatore.loreto@ericsson.com Wed Mar 2 05:40:31 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D243A67FB for ; Wed, 2 Mar 2011 05:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-t7zaFoe0YJ for ; Wed, 2 Mar 2011 05:40:30 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 628843A67F1 for ; Wed, 2 Mar 2011 05:40:30 -0800 (PST) X-AuditID: c1b4fb39-b7c6dae0000023f2-22-4d6e490e6ff2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 31.1A.09202.E094E6D4; Wed, 2 Mar 2011 14:41:35 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Wed, 2 Mar 2011 14:41:34 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 492FA297E for ; Wed, 2 Mar 2011 15:41:34 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 125E65090A for ; Wed, 2 Mar 2011 15:41:34 +0200 (EET) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BD23250844 for ; Wed, 2 Mar 2011 15:41:33 +0200 (EET) Message-ID: <4D6E490D.30805@ericsson.com> Date: Wed, 2 Mar 2011 15:41:33 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <20110301060349.GC9463@1wt.eu> <06E2327E-3CD0-447C-8A1B-132486D40466@gmail.com> In-Reply-To: <06E2327E-3CD0-447C-8A1B-132486D40466@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [hybi] http-timeout (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 13:40:31 -0000 On 3/2/11 1:02 AM, Brian McKelvey wrote: > Fwiw, I'd like to see this in the http headers rather than as some kind of hello frame. > > Brian > > Sent from my iPhone > > On Mar 1, 2011, at 2:51 PM, Greg Wilkins wrote: > >> > But do you think we should be disclosing idle timeouts at this stage, to help us develop those future plugins. > _____________________________________________ (as individual) last year Martin, Greg and I have written down the following (now expired) draft as a possible improvement for cometd (we presented it during the IETF meeting in Maastricht (in July 2010) during the APP area meeting) http://tools.ietf.org/id/draft-loreto-http-timeout-00.txt if there is enough interest we can refresh the draft (as an individual submission for the time being) and discuss in this wg cheers /Sal From salvatore.loreto@ericsson.com Wed Mar 2 05:46:43 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9560C3A67FC for ; Wed, 2 Mar 2011 05:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtTw7fRgpqPp for ; Wed, 2 Mar 2011 05:46:42 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id DF9F83A67D8 for ; Wed, 2 Mar 2011 05:46:41 -0800 (PST) X-AuditID: c1b4fb3d-b7bbbae000005311-db-4d6e4a829cf4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6A.78.21265.28A4E6D4; Wed, 2 Mar 2011 14:47:47 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Wed, 2 Mar 2011 14:47:44 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9BCD028AA for ; Wed, 2 Mar 2011 15:47:44 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5A9CB5090A for ; Wed, 2 Mar 2011 15:47:44 +0200 (EET) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0E81950844 for ; Wed, 2 Mar 2011 15:47:44 +0200 (EET) Message-ID: <4D6E4A7F.101@ericsson.com> Date: Wed, 2 Mar 2011 15:47:43 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 13:46:43 -0000 On 3/1/11 5:32 PM, John Tamplin wrote: > I would still like to move all control frames under a single CONTROL > opcode, and use the first byte of the payload to indicate the control > frame type -- I think it is useful to group control opcodes together > since we specifically do things differently for control frames (they > can't be fragmented, must use the short length format, and can be > injected in the middle of a fragmented data message), plus it frees up > some scarce opcodes and makes it nearly free to add more control > opcodes. > > However, there has never seemed to be much support for the idea when > proposed - maybe if we are wanting to add more control opcodes > (including Hello), the idea becomes more interesting. (as individual) I think the proposal has same value and it is worth to be discussed in a separate thread /Sal -- Salvatore Loreto www.sloreto.com From salvatore.loreto@ericsson.com Wed Mar 2 05:59:38 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC19A3A67E2 for ; Wed, 2 Mar 2011 05:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99uewWQd2QOw for ; Wed, 2 Mar 2011 05:59:37 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5558B3A67B7 for ; Wed, 2 Mar 2011 05:59:37 -0800 (PST) X-AuditID: c1b4fb3d-b7bbbae000005311-7b-4d6e4d8aab20 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 95.5A.21265.A8D4E6D4; Wed, 2 Mar 2011 15:00:42 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Wed, 2 Mar 2011 15:00:41 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8432128AA for ; Wed, 2 Mar 2011 16:00:41 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4DB3550940 for ; Wed, 2 Mar 2011 16:00:41 +0200 (EET) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 06B4C507FF for ; Wed, 2 Mar 2011 16:00:40 +0200 (EET) Message-ID: <4D6E4D88.10402@ericsson.com> Date: Wed, 2 Mar 2011 16:00:40 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary="------------020904060905040204000204" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [hybi] Ping and Pong control frames in 06 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 13:59:38 -0000 --------------020904060905040204000204 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi there I think the text about Ping, Pong control frames in 06 needs to be improved/clarified. At moment the only text is the following: 4.5.2. Ping The Ping message contains an opcode of 0x02. Upon receipt of a Ping message, an endpoint MUST send a Pong message in response. It SHOULD do so as soon as is practical. The message bodies of the Ping and Pong MUST be the same. I would propose to change the second paragraph in this way: / Upon sent of a Ping message, an endpoint MUST expect a Pong message in response. The message bodies of the Ping and Pong MUST be the same./ open issues #1: how long the end point has to wait before recognize the other peer is gone? open issues #2: what should do if the end point does not receive back a Pong (in a reasonable amount of time)? that is something I would like to be described in the specification. Do we need to specify an ad-hoc status code in the close frame for this particular case? 4.5.3. Pong The Pong message contains an opcode of 0x03. Upon receipt of a Ping message, an endpoint MUST send a Pong message in response. It SHOULD do so as soon as is practical. The message bodies of the Ping and Pong MUST be the same. A Pong is issued only in response to the most recent Ping. cheers /Sal -- Salvatore Loreto www.sloreto.com --------------020904060905040204000204 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi there

I think the text about Ping, Pong control frames in 06 needs to be improved/clarified.
At moment the only text is the following:

4.5.2.  Ping

   The Ping message contains an opcode of 0x02.

   Upon receipt of a Ping message, an endpoint MUST send a Pong message
   in response.  It SHOULD do so as soon as is practical.  The message
   bodies of the Ping and Pong MUST be the same.
I would propose to change the second paragraph in this way:


   Upon sent of a Ping message, an endpoint MUST expect a Pong message
   in response. The message bodies of the Ping and Pong MUST be the same.


open issues #1: how long the end point has to wait before recognize the other peer is gone?

open issues #2: what should do if the end point does not receive back a Pong (in a reasonable amount of time)?
    that is something I would like to be described in the specification.
    Do we need to specify an ad-hoc status code in the close frame for this particular case?


4.5.3.  Pong

   The Pong message contains an opcode of 0x03.

   Upon receipt of a Ping message, an endpoint MUST send a Pong message
   in response.  It SHOULD do so as soon as is practical.  The message
   bodies of the Ping and Pong MUST be the same.  A Pong is issued only
   in response to the most recent Ping.

cheers
/Sal
-- 
Salvatore Loreto
www.sloreto.com
--------------020904060905040204000204-- From buskanaka@gmail.com Wed Mar 2 06:58:03 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C988E3A6806 for ; Wed, 2 Mar 2011 06:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2olvyBqhOBOV for ; Wed, 2 Mar 2011 06:58:01 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 38B203A67A1 for ; Wed, 2 Mar 2011 06:58:01 -0800 (PST) Received: by ewy9 with SMTP id 9so4614ewy.31 for ; Wed, 02 Mar 2011 06:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=YneyQ/u6/fZs3gegCn9ie0M7zLsVf4TIq+dspCbttYM=; b=NEd7+LuDMkeBwkGTxKp5W8ii+hZ8YUC8mAHV+DZHjQXjxR+F633XUQneedKEuYQ4yQ S/WgtK4kiQtXnRODVDGnkk4DdD2sUtcEhcjt3rYyJb/7yE6A6KBFwIjRZbrr1VwIMNIT bocQeM+pYWfX9VkguX2NwbcQWai3xXLFW4PvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=PfdRC1I5katCrEHD2Ar+e2b6dyfLiLeOatJOCcvX4KAadRus8Kwz+PWa/U32h9mHZN zkFAI1+NQo6JtYtx8934eZxXtRAXI7L+o5gctUDShXqdwF+pyh42WKlGbhGjDNA8Vns3 xUPN4h8KSMjrXon8gzy2Pu8vvUDNnf449OnHg= Received: by 10.14.0.133 with SMTP id 5mr5634897eeb.10.1299077946488; Wed, 02 Mar 2011 06:59:06 -0800 (PST) MIME-Version: 1.0 Sender: buskanaka@gmail.com Received: by 10.14.119.136 with HTTP; Wed, 2 Mar 2011 06:58:46 -0800 (PST) In-Reply-To: References: From: Joel Martin Date: Wed, 2 Mar 2011 17:58:46 +0300 X-Google-Sender-Auth: MMpDz5HdJajJ2-2VF6KuJkD1EwE Message-ID: To: Silvio Ventres Content-Type: multipart/alternative; boundary=00504502d36e8939be049d81276a Cc: Bjoern Hoehrmann , hybi@ietf.org Subject: Re: [hybi] Masking debug capability proposition (WAS: Masking for WS data content) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 14:58:04 -0000 --00504502d36e8939be049d81276a Content-Type: text/plain; charset=ISO-8859-1 2011/2/26 Silvio Ventres > > PROPOSITION: > > Is it possible to include a section specifically allowing WS applications > to set > some kind of "debug" flag to set XOR mask to 0? > It's a reasonable request but it would have to be a browser configuration option (or UA) or at least always pop-up a security dialog, because allowing it to be set from the Javascript would make the masking useless since malicious Javascript is part of the threat model. As the most motivated person on the list, you should propose it with browser vendors (and/or the WebSockets API folks). Alternately you could code up a very simple WS proxy that could be run on the same system as the UA/browser and that would strip the masking and set the key to zeros before sending on to the real destination. Regards, Joel Martin --00504502d36e8939be049d81276a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2011/2/26 Silvio Ventres <<= a href=3D"mailto:silvio.ventres@gmail.com">silvio.ventres@gmail.com>=
PROPOSITION:

Is it possible to include a section specifically allowing WS applications t= o set
some kind of "debug" flag to set XOR mask to 0?
<= div>
It's a reasonable request but it would have to be a = browser configuration option (or UA) or at least always pop-up a security d= ialog, because allowing it to be set from the Javascript would make the mas= king useless since malicious Javascript is part of the threat model. As the= most motivated person on the list, you should propose it with browser vend= ors (and/or the WebSockets API folks). Alternately you could code up a very= simple WS proxy that could be run on the same system as the UA/browser and= that would strip the masking and set the key to zeros before sending on to= the real destination.

Regards,

Joel Martin
--00504502d36e8939be049d81276a-- From Gabriel.Montenegro@microsoft.com Wed Mar 2 10:59:47 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAA653A6844 for ; Wed, 2 Mar 2011 10:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.475 X-Spam-Level: X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzS3vBENcfHy for ; Wed, 2 Mar 2011 10:59:47 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id EB5453A6831 for ; Wed, 2 Mar 2011 10:59:46 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Mar 2011 11:00:52 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 2 Mar 2011 11:00:53 -0800 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.139]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Wed, 2 Mar 2011 11:00:52 -0800 From: Gabriel Montenegro To: Salvatore Loreto , "hybi@ietf.org" Thread-Topic: [hybi] http-timeout (was Re: Hello frames?) Thread-Index: AQHL2N+fL1uQ76fF2kOgcSRbwywYZJQaZkGA Date: Wed, 2 Mar 2011 19:00:50 +0000 Message-ID: References: <20110301060349.GC9463@1wt.eu> <06E2327E-3CD0-447C-8A1B-132486D40466@gmail.com> <4D6E490D.30805@ericsson.com> In-Reply-To: <4D6E490D.30805@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] http-timeout (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 18:59:47 -0000 I think it's fine to pursue this on a separate draft. Let's not deal with i= t within websockets, both because it is not specific to websockets (as seen= from the draft below) and to not add more stuff we need to converge on bef= ore 07 and Prague. > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of > Salvatore Loreto > Sent: Wednesday, March 02, 2011 05:42 > To: hybi@ietf.org > Subject: [hybi] http-timeout (was Re: Hello frames?) >=20 > On 3/2/11 1:02 AM, Brian McKelvey wrote: > > Fwiw, I'd like to see this in the http headers rather than as some kind= of hello > frame. > > > > Brian > > > > Sent from my iPhone > > > > On Mar 1, 2011, at 2:51 PM, Greg Wilkins wrote: > > > >> > But do you think we should be disclosing idle timeouts at this stag= e, to help > us develop those future plugins. > > _____________________________________________ > (as individual) >=20 > last year Martin, Greg and I have written down the following (now > expired) draft > as a possible improvement for cometd > (we presented it during the IETF meeting in Maastricht (in July 2010) dur= ing the > APP area meeting) >=20 > http://tools.ietf.org/id/draft-loreto-http-timeout-00.txt >=20 >=20 > if there is enough interest we can refresh the draft (as an individual su= bmission > for the time being) and discuss in this wg >=20 > cheers > /Sal >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From Gabriel.Montenegro@microsoft.com Wed Mar 2 11:00:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC11A3A6857 for ; Wed, 2 Mar 2011 11:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80Xns6tBVVp0 for ; Wed, 2 Mar 2011 11:00:33 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 7E39D3A684A for ; Wed, 2 Mar 2011 11:00:33 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Mar 2011 11:01:39 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 2 Mar 2011 11:01:39 -0800 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.139]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Wed, 2 Mar 2011 11:01:38 -0800 From: Gabriel Montenegro To: Salvatore Loreto , "hybi@ietf.org" Thread-Topic: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) Thread-Index: AQHL2OB1ClQDdm0Ct0CPbkBUrTUuwJQaZp7A Date: Wed, 2 Mar 2011 19:01:38 +0000 Message-ID: References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> In-Reply-To: <4D6E4A7F.101@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 19:00:34 -0000 Not sure I seem much need for HELLO, so I wouldn't call that a justificatio= n to reopen framing discussions. > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of > Salvatore Loreto > Sent: Wednesday, March 02, 2011 05:48 > To: hybi@ietf.org > Subject: [hybi] a single CONTROL opcode for all control frames (was Re: H= ello > frames?) >=20 > On 3/1/11 5:32 PM, John Tamplin wrote: > > I would still like to move all control frames under a single CONTROL > > opcode, and use the first byte of the payload to indicate the control > > frame type -- I think it is useful to group control opcodes together > > since we specifically do things differently for control frames (they > > can't be fragmented, must use the short length format, and can be > > injected in the middle of a fragmented data message), plus it frees up > > some scarce opcodes and makes it nearly free to add more control > > opcodes. > > > > However, there has never seemed to be much support for the idea when > > proposed - maybe if we are wanting to add more control opcodes > > (including Hello), the idea becomes more interesting. > (as individual) >=20 > I think the proposal has same value > and it is worth to be discussed in a separate thread >=20 >=20 > /Sal >=20 > -- > Salvatore Loreto > www.sloreto.com >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From Gabriel.Montenegro@microsoft.com Wed Mar 2 11:03:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0A43A684A for ; Wed, 2 Mar 2011 11:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.491 X-Spam-Level: X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uudw-TiTtRZu for ; Wed, 2 Mar 2011 11:03:03 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 731B53A6844 for ; Wed, 2 Mar 2011 11:03:03 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Mar 2011 11:04:09 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 2 Mar 2011 11:04:09 -0800 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.139]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Wed, 2 Mar 2011 11:04:09 -0800 From: Gabriel Montenegro To: Salvatore Loreto , "hybi@ietf.org" Thread-Topic: [hybi] Ping and Pong control frames in 06 Thread-Index: AQHL2OI+/ZL2Cu23Ak+YKZP2b0Rib5QaZtNQ Date: Wed, 2 Mar 2011 19:04:08 +0000 Message-ID: References: <4D6E4D88.10402@ericsson.com> In-Reply-To: <4D6E4D88.10402@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C1126EBF138TK5EX14MBXW602w_" MIME-Version: 1.0 Subject: Re: [hybi] Ping and Pong control frames in 06 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 19:03:08 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1126EBF138TK5EX14MBXW602w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't like "MUST expect". I much prefer normative language around observa= ble on-the-wire behavior. The question to ask is whether it is easy to tran= slate into a test case. So the previous "...MUST send a Pong message..." is= better, easily observable and testable. I much prefer the current paragraph instead of the proposed change. From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Sal= vatore Loreto Sent: Wednesday, March 02, 2011 06:01 To: hybi@ietf.org Subject: [hybi] Ping and Pong control frames in 06 Hi there I think the text about Ping, Pong control frames in 06 needs to be improved= /clarified. At moment the only text is the following: 4.5.2. Ping The Ping message contains an opcode of 0x02. Upon receipt of a Ping message, an endpoint MUST send a Pong message in response. It SHOULD do so as soon as is practical. The message bodies of the Ping and Pong MUST be the same. I would propose to change the second paragraph in this way: Upon sent of a Ping message, an endpoint MUST expect a Pong message in response. The message bodies of the Ping and Pong MUST be the same. open issues #1: how long the end point has to wait before recognize the oth= er peer is gone? open issues #2: what should do if the end point does not receive back a Pon= g (in a reasonable amount of time)? that is something I would like to be described in the specification. Do we need to specify an ad-hoc status code in the close frame for this= particular case? 4.5.3. Pong The Pong message contains an opcode of 0x03. Upon receipt of a Ping message, an endpoint MUST send a Pong message in response. It SHOULD do so as soon as is practical. The message bodies of the Ping and Pong MUST be the same. A Pong is issued only in response to the most recent Ping. cheers /Sal -- Salvatore Loreto www.sloreto.com --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1126EBF138TK5EX14MBXW602w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t like “= ;MUST expect”. I much prefer normative language around observable on-= the-wire behavior. The question to ask is whether it is easy to translate into a test case. So the previous “…MUST send a Pong message&#= 8230;” is better, easily observable and testable.

 <= /p>

I much prefer the current= paragraph instead of the proposed change.

 <= /p>

From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.o= rg] On Behalf Of Salvatore Loreto
Sent: Wednesday, March 02, 2011 06:01
To: hybi@ietf.org
Subject: [hybi] Ping and Pong control frames in 06=

 

Hi there

I think the text about Ping, Pong control frames in 06 needs to be improved= /clarified.
At moment the only text is the following:

4.5.2.  Ping
 
   The Ping message contains an opcode of 0x02.

 


   Upon receipt of a Ping message, an endpoint MUST send a P=
ong message


   in response.  It SHOULD do so as soon as is practica=
l.  The message


   bodies of the Ping and Pong MUST be the same.<=
/pre>

 


I would propose to ch=
ange the second paragraph in this way:





   Upon sent of a Ping message, an endpoint MUST expect a Pong=
 message

   in response. The message bodies of the Ping and Pong MUST be t=
he same.





open issues #1: how long the end point has to wait before recognize the oth=
er peer is gone?



open issues #2: what should do if the end point does not receive back a Pon=
g (in a reasonable amount of time)?

    that is something I would like to be described in the sp=
ecification.

    Do we need to specify an ad-hoc status code in the close=
 frame for this particular case?






4.5.3.  Pong


 


   The Pong message contains an opcode of 0x03.

 


   Upon receipt of a Ping message, an endpoint MUST send a P=
ong message


   in response.  It SHOULD do so as soon as is practica=
l.  The message


   bodies of the Ping and Pong MUST be the same.  A Pon=
g is issued only


   in response to the most recent Ping.




cheers

/Sal






-- 


Salvatore Loreto


www.sloreto.com
--_000_CA566BAEAD6B3F4E8B5C5C4F61710C1126EBF138TK5EX14MBXW602w_-- From jat@google.com Wed Mar 2 11:13:07 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7693A683F for ; Wed, 2 Mar 2011 11:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQpwGxEJQJ6O for ; Wed, 2 Mar 2011 11:13:06 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 77D023A6800 for ; Wed, 2 Mar 2011 11:13:05 -0800 (PST) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p22JEBNV011343 for ; Wed, 2 Mar 2011 11:14:11 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299093251; bh=uxaPUOODltGTabc1DeKZfoTzx6g=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=FTF9+b90vaAx1fFgax8Rk3zBQMY6vwcrAhYqTaKcEXJ9FVZ1wEFrsbr/O3BdtVuMo wB4ghCYIwjqhyk/Fcp4zA== Received: from ywo32 (ywo32.prod.google.com [10.192.15.32]) by hpaq12.eem.corp.google.com with ESMTP id p22JE9OV030391 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 2 Mar 2011 11:14:10 -0800 Received: by ywo32 with SMTP id 32so101187ywo.35 for ; Wed, 02 Mar 2011 11:14:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=OK5TQ9lFSk85U5HtbpeNkWqJTeF4vKITR2bRCEH1Z8I=; b=EdoW3y9y0L29PGGiTxbUrGEAmgSwj1xikZlsPkdq0hD9yMphKd5C9ujX0VcILGtV1v 330Xg5vgwN/b3/ZR+63w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ok647dCcdMnDCZa2JqxwyxVqyaG7YfcvZxG31Y+5bmmdnCMbsh0GBLTQ6M3NI1z3V/ XdzzKVZ3eJASZ5iuiB3w== Received: by 10.150.43.37 with SMTP id q37mr635859ybq.103.1299093249118; Wed, 02 Mar 2011 11:14:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Wed, 2 Mar 2011 11:13:49 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> From: John Tamplin Date: Wed, 2 Mar 2011 14:13:49 -0500 Message-ID: To: Gabriel Montenegro Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 19:13:07 -0000 On Wed, Mar 2, 2011 at 2:01 PM, Gabriel Montenegro wrote: > Not sure I seem much need for HELLO, so I wouldn't call that a justificat= ion to reopen framing discussions. My suggestion would be to define a CONTROL opcode, and then for that opcode the first byte of the payload defines which control frame is present. =C2=A0The reasons are: - it makes it easier to identify control frames, which are referenced elsewhere in the spec (limitations on size, fragmenting, and the ability to inject them in the middle of a fragmented data message. When new control frames are added, the check for whether something is a control frame or not remains accurate - the number of available opcodes seems small, and over time it seems certain we will need to define a way of extending them at some point, similar to what I propose. Control frames should be much less frequent than data frames, so using an extra byte for control frames instead of some future data frame type will be more efficient. - by having a larger number of control opcodes available with practically no additional cost, proposals for a new control frame that is somewhat speculative won't see resistance solely about using scarce opcode resources. -- John A. Tamplin Software Engineer (GWT), Google From ferg@caucho.com Wed Mar 2 11:21:07 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59B8E3A6849 for ; Wed, 2 Mar 2011 11:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv3FwE9Z08y4 for ; Wed, 2 Mar 2011 11:21:03 -0800 (PST) Received: from nm6.bullet.mail.ne1.yahoo.com (nm6.bullet.mail.ne1.yahoo.com [98.138.90.69]) by core3.amsl.com (Postfix) with SMTP id 2469D3A6823 for ; Wed, 2 Mar 2011 11:21:03 -0800 (PST) Received: from [98.138.90.51] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 02 Mar 2011 19:22:09 -0000 Received: from [98.138.87.5] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 02 Mar 2011 19:22:09 -0000 Received: from [127.0.0.1] by omp1005.mail.ne1.yahoo.com with NNFMP; 02 Mar 2011 19:22:09 -0000 X-Yahoo-Newman-Id: 461912.12245.bm@omp1005.mail.ne1.yahoo.com Received: (qmail 34583 invoked from network); 2 Mar 2011 19:22:08 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp115.biz.mail.mud.yahoo.com with SMTP; 02 Mar 2011 11:22:07 -0800 PST X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: zm_vD1cVM1k8obwur9eLQEMqJL_wEBo3MdgFFgJz_BAfEg8 iiRxotjdV.ddF_KMWyuQ.CxWijpt2J4NFm_R7IQ1OTif_Wgpiqs0ANGSvEsa Fn6TLbGXEEYQegGpf_boAnVmW8w__KsD0UKMjbSNEnP8VsrKc2m_HOw7ueFn cLs7lWpOWbEKvYeSCSNMuYEGkmbCi2H.cHKhbFHJzKeXYj2fOhNzLlsTgt8K auSGS3MoKxrdg29fml1zgx2lG89PTjp_ffezhSBH0qHotBXVkeW6tOwW3NYJ q2BrgsuJVuRB5.BPYUKIwRIiDPzlRg83faEJ1N0u5a7TIoM4NSr_8NiH9cb5 hwXDJWTUprgqAEKKc4mzUCU6z7IRxcLcBzfBKAA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D6E98DF.1040603@caucho.com> Date: Wed, 02 Mar 2011 11:22:07 -0800 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4D6E4D88.10402@ericsson.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010505070305020804050101" Subject: Re: [hybi] Ping and Pong control frames in 06 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 19:21:07 -0000 This is a multi-part message in MIME format. --------------010505070305020804050101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/02/2011 11:04 AM, Gabriel Montenegro wrote: > > I don't like "MUST expect". I much prefer normative language around > observable on-the-wire behavior. The question to ask is whether it is > easy to translate into a test case. So the previous "...MUST send a > Pong message..." is better, easily observable and testable. > > I much prefer the current paragraph instead of the proposed change. > I'd also prefer the current language. An early discussion of keepalives suggested unidirectional keepalives as a better solution for some contexts (possibly some mobile applications for saving battery?), and I thought one of the reasons for the PING/PONG was to allow for unsolicited PONGs to implement that unidirectional heartbeat. Was that idea abandoned? -- Scott > *From:*hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] *On Behalf > Of *Salvatore Loreto > *Sent:* Wednesday, March 02, 2011 06:01 > *To:* hybi@ietf.org > *Subject:* [hybi] Ping and Pong control frames in 06 > > Hi there > > I think the text about Ping, Pong control frames in 06 needs to be > improved/clarified. > At moment the only text is the following: > > 4.5.2. Ping > > The Ping message contains an opcode of 0x02. > > Upon receipt of a Ping message, an endpoint MUST send a Pong message > in response. It SHOULD do so as soon as is practical. The message > bodies of the Ping and Pong MUST be the same. > > > I would propose to change the second paragraph in this way: > > > / Upon sent of a Ping message, an endpoint MUST expect a Pong message > in response. The message bodies of the Ping and Pong MUST be the same./ > > > open issues #1: how long the end point has to wait before recognize > the other peer is gone? > > open issues #2: what should do if the end point does not receive back > a Pong (in a reasonable amount of time)? > that is something I would like to be described in the specification. > Do we need to specify an ad-hoc status code in the close frame for > this particular case? > > 4.5.3. Pong > > The Pong message contains an opcode of 0x03. > > Upon receipt of a Ping message, an endpoint MUST send a Pong message > in response. It SHOULD do so as soon as is practical. The message > bodies of the Ping and Pong MUST be the same. A Pong is issued only > in response to the most recent Ping. > > > cheers > /Sal > > -- > Salvatore Loreto > www.sloreto.com > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --------------010505070305020804050101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/02/2011 11:04 AM, Gabriel Montenegro wrote:

I don’t like “MUST expect”. I much prefer normative language around observable on-the-wire behavior. The question to ask is whether it is easy to translate into a test case. So the previous “…MUST send a Pong message…” is better, easily observable and testable.

 

I much prefer the current paragraph instead of the proposed change.


I'd also prefer the current language.

An early discussion of keepalives suggested unidirectional keepalives as a better solution for some contexts (possibly some mobile applications for saving battery?), and I thought one of the reasons for the PING/PONG was to allow for unsolicited PONGs to implement that unidirectional heartbeat.

Was that idea abandoned?

-- Scott

 

From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Salvatore Loreto
Sent: Wednesday, March 02, 2011 06:01
To: hybi@ietf.org
Subject: [hybi] Ping and Pong control frames in 06

 

Hi there

I think the text about Ping, Pong control frames in 06 needs to be improved/clarified.
At moment the only text is the following:

4.5.2.  Ping
 
   The Ping message contains an opcode of 0x02.
 
   Upon receipt of a Ping message, an endpoint MUST send a Pong message
   in response.  It SHOULD do so as soon as is practical.  The message
   bodies of the Ping and Pong MUST be the same.
 

I would propose to change the second paragraph in this way:


   Upon sent of a Ping message, an endpoint MUST expect a Pong message
   in response. The message bodies of the Ping and Pong MUST be the same.


open issues #1: how long the end point has to wait before recognize the other peer is gone?

open issues #2: what should do if the end point does not receive back a Pong (in a reasonable amount of time)?
    that is something I would like to be described in the specification.
    Do we need to specify an ad-hoc status code in the close frame for this particular case?

4.5.3.  Pong
 
   The Pong message contains an opcode of 0x03.
 
   Upon receipt of a Ping message, an endpoint MUST send a Pong message
   in response.  It SHOULD do so as soon as is practical.  The message
   bodies of the Ping and Pong MUST be the same.  A Pong is issued only
   in response to the most recent Ping.


cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

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

--------------010505070305020804050101-- From salvatore.loreto@ericsson.com Wed Mar 2 11:50:18 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A57F3A6863 for ; Wed, 2 Mar 2011 11:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucU6dPtFyHla for ; Wed, 2 Mar 2011 11:50:17 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 25B7E3A6831 for ; Wed, 2 Mar 2011 11:50:15 -0800 (PST) X-AuditID: c1b4fb3d-b7bbbae000005311-83-4d6e9fb98526 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 27.BC.21265.9BF9E6D4; Wed, 2 Mar 2011 20:51:21 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Wed, 2 Mar 2011 20:51:21 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EC15D28AA; Wed, 2 Mar 2011 21:51:20 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B51605090A; Wed, 2 Mar 2011 21:51:20 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 59CF1508DB; Wed, 2 Mar 2011 21:51:20 +0200 (EET) Message-ID: <4D6E9FB8.4090506@ericsson.com> Date: Wed, 2 Mar 2011 21:51:20 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Gabriel Montenegro References: <4D6E4D88.10402@ericsson.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030408050000040407030109" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] Ping and Pong control frames in 06 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 19:50:18 -0000 --------------030408050000040407030109 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit my point was that in the 4.5.2 Ping section I expect to read something relate to 1) what the Ping is for 2) what should do a peer after have sent a PING 2.1) wait for a certain amount of time (we can specify it or leave it unspecified both are OK for me) 2.1) what to do if a PONG is not received so whatever is the text the two open issues I have described below still have to be addressed in the text On 3/2/11 9:04 PM, Gabriel Montenegro wrote: > > I don’t like “MUST expect”. I much prefer normative language around > observable on-the-wire behavior. The question to ask is whether it is > easy to translate into a test case. So the previous “…MUST send a Pong > message…” is better, easily observable and testable. > > I much prefer the current paragraph instead of the proposed change. > > *From:*hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] *On Behalf > Of *Salvatore Loreto > *Sent:* Wednesday, March 02, 2011 06:01 > *To:* hybi@ietf.org > *Subject:* [hybi] Ping and Pong control frames in 06 > > Hi there > > I think the text about Ping, Pong control frames in 06 needs to be > improved/clarified. > At moment the only text is the following: > > 4.5.2. Ping > > The Ping message contains an opcode of 0x02. > > Upon receipt of a Ping message, an endpoint MUST send a Pong message > in response. It SHOULD do so as soon as is practical. The message > bodies of the Ping and Pong MUST be the same. > > > I would propose to change the second paragraph in this way: > > > / Upon sent of a Ping message, an endpoint MUST expect a Pong message > in response. The message bodies of the Ping and Pong MUST be the same./ > > > open issues #1: how long the end point has to wait before recognize > the other peer is gone? > > open issues #2: what should do if the end point does not receive back > a Pong (in a reasonable amount of time)? > that is something I would like to be described in the specification. > Do we need to specify an ad-hoc status code in the close frame for > this particular case? > > 4.5.3. Pong > > The Pong message contains an opcode of 0x03. > > Upon receipt of a Ping message, an endpoint MUST send a Pong message > in response. It SHOULD do so as soon as is practical. The message > bodies of the Ping and Pong MUST be the same. A Pong is issued only > in response to the most recent Ping. > > > cheers > /Sal > --------------030408050000040407030109 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit
my point was that in the 4.5.2 Ping section I expect to read something relate to
1) what the Ping is for
2) what should do a peer after have sent a PING
    2.1) wait for a certain amount of time (we can specify it or leave it unspecified both are OK for me)
    2.1) what to do if a PONG is not received

so whatever is the text the two open issues I have described below still have to be addressed in the text


On 3/2/11 9:04 PM, Gabriel Montenegro wrote:

I don’t like “MUST expect”. I much prefer normative language around observable on-the-wire behavior. The question to ask is whether it is easy to translate into a test case. So the previous “…MUST send a Pong message…” is better, easily observable and testable.

 

I much prefer the current paragraph instead of the proposed change.

 

From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Salvatore Loreto
Sent: Wednesday, March 02, 2011 06:01
To: hybi@ietf.org
Subject: [hybi] Ping and Pong control frames in 06

 

Hi there

I think the text about Ping, Pong control frames in 06 needs to be improved/clarified.
At moment the only text is the following:

4.5.2.  Ping
 
   The Ping message contains an opcode of 0x02.
 
   Upon receipt of a Ping message, an endpoint MUST send a Pong message
   in response.  It SHOULD do so as soon as is practical.  The message
   bodies of the Ping and Pong MUST be the same.
 

I would propose to change the second paragraph in this way:


   Upon sent of a Ping message, an endpoint MUST expect a Pong message
   in response. The message bodies of the Ping and Pong MUST be the same.


open issues #1: how long the end point has to wait before recognize the other peer is gone?

open issues #2: what should do if the end point does not receive back a Pong (in a reasonable amount of time)?
    that is something I would like to be described in the specification.
    Do we need to specify an ad-hoc status code in the close frame for this particular case?

4.5.3.  Pong
 
   The Pong message contains an opcode of 0x03.
 
   Upon receipt of a Ping message, an endpoint MUST send a Pong message
   in response.  It SHOULD do so as soon as is practical.  The message
   bodies of the Ping and Pong MUST be the same.  A Pong is issued only
   in response to the most recent Ping.


cheers
/Sal

--------------030408050000040407030109-- From gregw@intalio.com Wed Mar 2 12:43:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3856E3A68AE for ; Wed, 2 Mar 2011 12:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpACD5oVvWuC for ; Wed, 2 Mar 2011 12:43:35 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id F24623A6850 for ; Wed, 2 Mar 2011 12:43:34 -0800 (PST) Received: by vws6 with SMTP id 6so362294vws.31 for ; Wed, 02 Mar 2011 12:44:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.68.175 with SMTP id x15mr478363vdt.70.1299098680991; Wed, 02 Mar 2011 12:44:40 -0800 (PST) Sender: gregw@intalio.com Received: by 10.52.165.129 with HTTP; Wed, 2 Mar 2011 12:44:40 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> Date: Thu, 3 Mar 2011 07:44:40 +1100 X-Google-Sender-Auth: 2XLPSVy-ZWaqCrZw4V4nEwgA-nw Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: multipart/alternative; boundary=20cf3078131e68a122049d85fb58 Cc: "hybi@ietf.org" , Gabriel Montenegro Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 20:43:36 -0000 --20cf3078131e68a122049d85fb58 Content-Type: text/plain; charset=ISO-8859-1 On 3 March 2011 06:13, John Tamplin wrote: > - it makes it easier to identify control frames, which are referenced > elsewhere in the spec (limitations on size, fragmenting, and the > ability to inject them in the middle of a fragmented data message. > When new control frames are added, the check for whether something is > a control frame or not remains accurate +1 on this reasoning > - the number of available opcodes seems small, and over time it seems > certain we will need to define a way of extending them at some point, > similar to what I propose. Control frames should be much less > frequent than data frames, so using an extra byte for control frames > instead of some future data frame type will be more efficient. -1 on this. There are spare opcodes and currently there does not appear to be great demand for them. If there was, then we would be free to create an opcode that means - look for the real opcode in the first byte of payload. This is essentially what you are proposing, but we can defer until needed. > - by having a larger number of control opcodes available with > practically no additional cost, proposals for a new control frame that > is somewhat speculative won't see resistance solely about using scarce > opcode resources. +0 I think opcodes should always be well allocated, no matter how plentiful. So to repost my counter proposal. We can partition the current opcodes into normal and control: frame-opcode = %x0 ; continuation frame / %x1 ; text frame / %x2 ; binary frame / %x3-7 ; reserved / frame-control-opcode frame-control-opcode = %x8 ; ping / %x9 ; pong / %xA-E ; reserved / %xF ; close cheers > -- > John A. Tamplin > Software Engineer (GWT), Google > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --20cf3078131e68a122049d85fb58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 3 March 2011 06:13, John Tamplin <jat@google.com> wrote:
> - it makes it easier to identi= fy control frames, which are referenced
> elsewhere in the spec (limi= tations on size, fragmenting, and the
> ability to inject them in the middle of a fragmented data message.
= > When new control frames are added, the check for whether something is<= br>> a control frame or not remains accurate

+1 on this reasoning=


> - the number of available opcodes seems small, and over time i= t seems
> certain we will need to define a way of extending them at s= ome point,
> similar to what I propose. =A0Control frames should be m= uch less
> frequent than data frames, so using an extra byte for control frames> instead of some future data frame type will be more efficient.
-1 on this.

There are spare opcodes and currently there does not a= ppear to be great demand for them.
If there was, then we would be free to create an opcode that means - look f= or the real opcode in the first byte of payload. =A0 This is essentially wh= at you are proposing, but we can defer until needed.


> - by h= aving a larger number of control opcodes available with
> practically no additional cost, proposals for a new control frame that=
> is somewhat speculative won't see resistance solely about usin= g scarce
> opcode resources.

+0 =A0 I think opcodes should alw= ays be well allocated, no matter how plentiful.



So to repost my counter proposal.=A0 We can partition the curre= nt opcodes into normal and control:

frame-opcode =3D %x0 ; continuation frame
=A0 =A0 =A0 =A0 =A0 =A0= =A0 / %x1 ; text frame
=A0 =A0 =A0 =A0 =A0 = =A0=A0 / %x2 ; binary frame
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 / %x3-7 ; reserved
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 / frame-control-opcode
<= br>frame-control-opcode =3D %x8 ; ping
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 / %x9 ; pong
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 / %xA-E ; reserve= d
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 / %xF ; close<= br style=3D"font-family:courier new,monospace"> =A0=A0
cheers





> --
> John A. Tamplin
> = Software Engineer (GWT), Google
> ___________________________________= ____________
> hybi mailing list
> hybi@ietf.o= rg
> https= ://www.ietf.org/mailman/listinfo/hybi
>

--20cf3078131e68a122049d85fb58-- From jat@google.com Wed Mar 2 12:56:19 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6BE43A6882 for ; Wed, 2 Mar 2011 12:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.931 X-Spam-Level: X-Spam-Status: No, score=-105.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JlpkUUTTrgd for ; Wed, 2 Mar 2011 12:56:18 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 768E73A686E for ; Wed, 2 Mar 2011 12:56:18 -0800 (PST) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id p22KvNaH017623 for ; Wed, 2 Mar 2011 12:57:23 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299099444; bh=qS+jIWsjDglWNL7Bk/9DPPE5PuM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Zca3ON06Xs9FCJYB7iNEymIM3WoWCp+RYxO2CNcBEpj/M1twMo2o7LJBS5ciivoaw gGKcY3DbR35DytODSuxbA== Received: from gwj20 (gwj20.prod.google.com [10.200.10.20]) by kpbe11.cbf.corp.google.com with ESMTP id p22KuBTC010769 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 2 Mar 2011 12:57:22 -0800 Received: by gwj20 with SMTP id 20so165979gwj.7 for ; Wed, 02 Mar 2011 12:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=+IVgbMZ9VpI5muaiFaaLd0DpHA5vXvac+MsD9M0OVjI=; b=P+4IHQ84TydCnunPpi+aFmdUOoz+1/uyAb9yuIUAql+568WuGym9fFApdgXrHvdu0w wZOoNc5AG5V8lFUlLj/Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=twFWnXlRzJN7UhJ3epCc2U4ZXWjnt9z/8tmlmTNGwLNznqscFzW5WgBD+zd18t8K79 ZQYEM4UzI3xWfpdsjR3A== Received: by 10.150.43.37 with SMTP id q37mr777334ybq.103.1299099442175; Wed, 02 Mar 2011 12:57:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Wed, 2 Mar 2011 12:57:02 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> From: John Tamplin Date: Wed, 2 Mar 2011 15:57:02 -0500 Message-ID: To: Greg Wilkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "hybi@ietf.org" , Gabriel Montenegro Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 20:56:19 -0000 On Wed, Mar 2, 2011 at 3:44 PM, Greg Wilkins wrote: > > - the number of available opcodes seems small, and over time it seems > > certain we will need to define a way of extending them at some point, > > similar to what I propose. =C2=A0Control frames should be much less > > frequent than data frames, so using an extra byte for control frames > > instead of some future data frame type will be more efficient. > > -1 on this. > > There are spare opcodes and currently there does not appear to be great d= emand for them. > > If there was, then we would be free to create an opcode that means - look= for the real opcode > in the first byte of payload. =C2=A0 This is essentially what you are pro= posing, but we can defer until > needed. In the discussions of framing, there were many different proposals of potential extensions, and there were two primary methods proposed for them - extension metadata and extension opcodes. =C2=A0To get a framing spec done, we compromised on a middle-ground that allows both, but also means there are fewer opcodes available. =C2=A0If all of those extensions being discussed every happened, we would already be out of opcodes and that's with what we can think of today, much less the next 5 or 10 years. > +0 =C2=A0 I think opcodes should always be well allocated, no matter how = plentiful. As an example, I haven't seen anything suggested from a Hello frame that would make me think the value of including it now outweighs the cost of using a scarce opcode. =C2=A0If instead it is using an extended control opcode out of 256, then I am less inclined to object to using one of the opcodes for something I don't personally see much value in that others do. > So to repost my counter proposal.=C2=A0 We can partition the current opco= des into normal and control: > > frame-opcode =3D %x0 ; continuation frame > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 / %x1 ; text frame > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 / %x2 ; binary frame > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = / %x3-7 ; reserved > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = / frame-control-opcode > > frame-control-opcode =3D %x8 ; ping > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 / %x9 ; pong > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 / %xA-E ; reserved > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 / %xF ; close My objection to this is that we still are defining now exactly how many control opcodes there are and how many data opcodes there are, and we don't know how many we will need of either. =C2=A0Code is likely to be written that defines isControl(opcode) as opcode & 8, so when we need to create extension opcode space would that mean we need to have two primary opcodes allocated, one for extended data opcodes and one for extended control opcodes? Also, what happens if we decide that we don't need as many reserved bits for per-frame flags, but we do need more opcodes so we allocate adjacent reserved bits to the opcode field? =C2=A0Is control-ness of an opcode still based on the 0x8 bit? -- John A. Tamplin Software Engineer (GWT), Google From gregw@intalio.com Wed Mar 2 13:24:19 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A056D3A6850 for ; Wed, 2 Mar 2011 13:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mtPx4mBYyfx for ; Wed, 2 Mar 2011 13:24:19 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id CBE303A6816 for ; Wed, 2 Mar 2011 13:24:18 -0800 (PST) Received: by vxg33 with SMTP id 33so430641vxg.31 for ; Wed, 02 Mar 2011 13:25:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.97.130 with SMTP id ea2mr487656vdb.230.1299101125179; Wed, 02 Mar 2011 13:25:25 -0800 (PST) Sender: gregw@intalio.com Received: by 10.52.165.129 with HTTP; Wed, 2 Mar 2011 13:25:25 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> Date: Thu, 3 Mar 2011 08:25:25 +1100 X-Google-Sender-Auth: 90fHsk6R-r_brQw5Cn6IOkxBLxA Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: multipart/alternative; boundary=20cf307cfc7817f991049d868d79 Cc: "hybi@ietf.org" , Gabriel Montenegro Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 21:24:19 -0000 --20cf307cfc7817f991049d868d79 Content-Type: text/plain; charset=ISO-8859-1 John, your proposal still sets a limit on the number of normal/control op-codes as15/, while my proposal is 8/8. If you exhaust the 15 normal codes, then another primary opcode would have to be allocated, it is the same for both proposals. I think we are basically saying the same thing, the only real difference is that you split primary normal/control opcodes as 15/1 and assume that we need to immediately go for 0/256 in the payload. I'm proposing we split 8/8 and go for 256/0, 0/256 or 256/256 in the payload only when we need to. Eitherway, I'm supportive of the basic premise if a clear indication of what are control frames. Your proposal is totally workable - but I have a slight preference for my variation. cheers --20cf307cfc7817f991049d868d79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

John,

your proposal still sets a limit on the number of norm= al/control op-codes as15/, while my proposal=A0 is 8/8. If you exhaust the = 15 normal codes, then another primary opcode would have to be allocated, it= is the same for both proposals.

I think we are basically saying the same thing, the only real differenc= e is that you split primary normal/control opcodes as 15/1 and assume that = we need to immediately go for=A0 0/256 in the payload.=A0=A0=A0=A0 I'm = proposing we split 8/8 and go for 256/0, 0/256 or 256/256 in the payload on= ly when we need to.

Eitherway, I'm supportive of the basic premise if a clear indicatio= n of what are control frames.=A0 Your proposal is totally workable - but I = have a slight preference for my variation.

cheers

--20cf307cfc7817f991049d868d79-- From bruce@callenish.com Wed Mar 2 18:52:23 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C01C53A6927 for ; Wed, 2 Mar 2011 18:52:23 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+jQMr6+5iRQ for ; Wed, 2 Mar 2011 18:52:22 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id D28353A6403 for ; Wed, 2 Mar 2011 18:52:22 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.103]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1PuyfP-0003ep-60; Wed, 02 Mar 2011 18:53:27 -0800 Message-ID: <4D6F02A7.4090107@callenish.com> Date: Wed, 02 Mar 2011 18:53:27 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Andy Green References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <33B46028-223B-48C6-AA17-88FBE046E064@gmail.com> <4D6CA212.40204@warmcat.com> <1298990407.2498.671.camel@ds9.ducksong.com> <4D6D0991.8000203@warmcat.com> In-Reply-To: <4D6D0991.8000203@warmcat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 02:52:23 -0000 On 01/03/2011 6:58 AM, Andy Green wrote: > On 03/01/2011 02:40 PM, Somebody in the thread at some point said: >> >> Being transported on a stream based protocol, it is screwed whenever it >> misses the handshake as it cannot be sure where the frame starts even in >> the total absence of an asymmetric mask. If it has the handshake, then >> there is no problem, if it misses it then it has to apply a pile of >> heuristics - which still seems quite doable with masking (i.e. port >> numbers, testing likely bytes for known opcodes, testing them with the >> mask, etc..). > > Well, you're right. > > But two points ameliorate that, one is that the snooper only needs to > achieve sync at the start of its snooping session and it won't lose it > again if it's genuinely synced. > > The second point is the data on a websocket link is probably critical > for latency so it will try to issue what it has quite quickly, and > likely bursty, so sometimes there's no traffic. If the server makes a > new frame at a packet boundary you are very likely to find a websocket > header at the start of the first network packet after a period of > being idle. > > If the data on the link doesn't fit that profile, eg it's audio that's > always coming at a fixed rate, but the server spilling packets is done > at a smaller amount of data than the frame length, yeah it'll be > difficult to know what you're looking at. > Exactly. You may have to scan a few packets before you find the start of a frame, but it shouldn't be all that different from scanning an HTTP stream looking for the beginning of a request or response. And if you know whether to unmask a particular set of packets or not, the heuristic for finding the start of a frame becomes a lot easier to work with. This is especially true if you know what to look for in the particular payload types that are being sent (it could be XML, or fragments of audio data that you can try playing). I would imagine that it won't be uncommon to turn off nagling of the packets. Even when they are nagled, I would imagine it would be fairly common that a packet containing multiple frames would still start with a frame header unless there was a continuous stream of small frames being sent. Also, that people might choose smaller frame sizes even in applications with large message sizes to reduce the debugging burden as well as to reduce the latency of control messages. As you say, once you have the start of one frame, you are golden and can determine everything that comes afterward. But getting there is much easier if you can identify candidate packets for starting a frame without first unmasking them (supporting Greg's proposal not to mask the frame) and if you don't need to test every candidate packet twice because the framing tells you whether masking is present or not. From theturtle32@gmail.com Wed Mar 2 20:09:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0BF3A695D for ; Wed, 2 Mar 2011 20:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvUu0zT-7XrN for ; Wed, 2 Mar 2011 20:09:57 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 4E0F53A695C for ; Wed, 2 Mar 2011 20:09:57 -0800 (PST) Received: by iyj8 with SMTP id 8so670994iyj.31 for ; Wed, 02 Mar 2011 20:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=0AcJx6cqvqZq4XYF8epo2luVVR5cmQzM0rkibfiD3YU=; b=iX+Y0vRp+qa6+x7VUwFr016LU6nUij+4S+4fC+d1h4qccFAclnG0icJ+NWbkBwXeta HcNYXx651OXfOZ5YIYJKUZKPFFlIGMOpvF5Q1i+9gJfQtV6zacbnXRLY4e96rNyoUVF5 DTDJmtmlWJbkudCwEhnyK1bRwgcvUZYFtJVeQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=KOmATI1whKio+fVSdMkcX+N5c/b0aYUWTpJddb9GHbizRfp8NS9jJg2MPZar7jl+K/ t5KV58fFEOaiTfW9yp74qWk0kKuZuFb2UfTgQmHxkBJY3Da0l85S7Qhot4NcySGS1uBm BDl8XXs4DsTvx2L4xWjcPIbtYOs/jfkSdT1pw= Received: by 10.42.178.135 with SMTP id bm7mr1141905icb.158.1299125463976; Wed, 02 Mar 2011 20:11:03 -0800 (PST) Received: from [10.20.46.108] ([166.205.140.213]) by mx.google.com with ESMTPS id wh3sm427261icb.0.2011.03.02.20.11.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Mar 2011 20:11:02 -0800 (PST) References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <33B46028-223B-48C6-AA17-88FBE046E064@gmail.com> <4D6CA212.40204@warmcat.com> <1298990407.2498.671.camel@ds9.ducksong.com> <4D6D0991.8000203@warmcat.com> <4D6F02A7.4090107@callenish.com> In-Reply-To: <4D6F02A7.4090107@callenish.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148) From: Brian McKelvey Date: Wed, 2 Mar 2011 20:10:53 -0800 To: Bruce Atherton Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 04:09:58 -0000 Indeed. I'm not ready to let this go yet. It's perfectly logical and reaso= nable that the frame header can be unmasked while still maintaining mandator= y masking of the extension and payload data. This is a supremely simple cha= nge with no actual security risk. The real possibility that an attack of an= y substance could be carried out using only the fields manipulable by the js= api in the framing (field length) is absurdly remote to the point of non-ex= istence in practicality. Brian Sent from my iPhone On Mar 2, 2011, at 6:53 PM, Bruce Atherton wrote: > On 01/03/2011 6:58 AM, Andy Green wrote: >> On 03/01/2011 02:40 PM, Somebody in the thread at some point said: >>>=20 >>> Being transported on a stream based protocol, it is screwed whenever it >>> misses the handshake as it cannot be sure where the frame starts even in= >>> the total absence of an asymmetric mask. If it has the handshake, then >>> there is no problem, if it misses it then it has to apply a pile of >>> heuristics - which still seems quite doable with masking (i.e. port >>> numbers, testing likely bytes for known opcodes, testing them with the >>> mask, etc..). >>=20 >> Well, you're right. >>=20 >> But two points ameliorate that, one is that the snooper only needs to ach= ieve sync at the start of its snooping session and it won't lose it again if= it's genuinely synced. >>=20 >> The second point is the data on a websocket link is probably critical for= latency so it will try to issue what it has quite quickly, and likely burst= y, so sometimes there's no traffic. If the server makes a new frame at a pa= cket boundary you are very likely to find a websocket header at the start of= the first network packet after a period of being idle. >>=20 >> If the data on the link doesn't fit that profile, eg it's audio that's al= ways coming at a fixed rate, but the server spilling packets is done at a sm= aller amount of data than the frame length, yeah it'll be difficult to know w= hat you're looking at. >>=20 >=20 > Exactly. You may have to scan a few packets before you find the start of a= frame, but it shouldn't be all that different from scanning an HTTP stream l= ooking for the beginning of a request or response. And if you know whether t= o unmask a particular set of packets or not, the heuristic for finding the s= tart of a frame becomes a lot easier to work with. This is especially true i= f you know what to look for in the particular payload types that are being s= ent (it could be XML, or fragments of audio data that you can try playing). >=20 > I would imagine that it won't be uncommon to turn off nagling of the packe= ts. Even when they are nagled, I would imagine it would be fairly common tha= t a packet containing multiple frames would still start with a frame header u= nless there was a continuous stream of small frames being sent. Also, that p= eople might choose smaller frame sizes even in applications with large messa= ge sizes to reduce the debugging burden as well as to reduce the latency of c= ontrol messages. >=20 > As you say, once you have the start of one frame, you are golden and can d= etermine everything that comes afterward. But getting there is much easier i= f you can identify candidate packets for starting a frame without first unma= sking them (supporting Greg's proposal not to mask the frame) and if you don= 't need to test every candidate packet twice because the framing tells you w= hether masking is present or not. >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From theturtle32@gmail.com Wed Mar 2 20:12:05 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B13B3A6943 for ; Wed, 2 Mar 2011 20:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FEpEbVpknjy for ; Wed, 2 Mar 2011 20:12:04 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 779053A6959 for ; Wed, 2 Mar 2011 20:12:04 -0800 (PST) Received: by iwl42 with SMTP id 42so699021iwl.31 for ; Wed, 02 Mar 2011 20:13:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=FCJ9KBMfGrDJsa4bLRhQhNtB8EeLifG3s2RxVYHAjnc=; b=nldp2Eun9FEgSP1RVY+nsABDn6HIVluhb014Bof4iH/IrSy80DFebAN931+hH8VD4m eRAXQMEqY4S1P4xIwCIzAP6Fn5T4Qm3zIyHwjqyabMG/d7GNEtFCGie4SiH2OhFpeB0A 68D1H7TQiGPcHaKzpc1qeYAqtKqDxQGRAu4ZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=stLgfr0945Y11wr+k0j0o1p3AMMMz0BiXThpNGvLb/m3Azm7HVWXaSmS/9KxJq7bfN wzuGOTSbS70OErpb+PRn9fy9u9fXn2cIFPunmp1bHq0zFMbGL6TikrqIW3PWp9HeZ14G TUOha3uCjhcEPLHo9YwPCT4EoYQUqI4im+vpk= Received: by 10.42.220.138 with SMTP id hy10mr930300icb.271.1299125589711; Wed, 02 Mar 2011 20:13:09 -0800 (PST) Received: from [10.20.46.108] ([166.205.140.213]) by mx.google.com with ESMTPS id g4sm413907ick.23.2011.03.02.20.13.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Mar 2011 20:13:08 -0800 (PST) References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <33B46028-223B-48C6-AA17-88FBE046E064@gmail.com> <4D6CA212.40204@warmcat.com> <1298990407.2498.671.camel@ds9.ducksong.com> <4D6D0991.8000203@warmcat.com> <4D6F02A7.4090107@callenish.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7AC6D391-F987-4A8E-8BA9-6EB17E16366A@gmail.com> X-Mailer: iPhone Mail (8C148) From: Brian McKelvey Date: Wed, 2 Mar 2011 20:13:01 -0800 To: Brian McKelvey Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 04:12:05 -0000 Upon re-reading I wanted to make it clear that when I said "the frame header= can be unmasked" I meant transmitted in the clear to begin with. Sent from my iPhone On Mar 2, 2011, at 8:10 PM, Brian McKelvey wrote: > Indeed. I'm not ready to let this go yet. It's perfectly logical and rea= sonable that the frame header can be unmasked while still maintaining mandat= ory masking of the extension and payload data. This is a supremely simple c= hange with no actual security risk. The real possibility that an attack of a= ny substance could be carried out using only the fields manipulable by the j= s api in the framing (field length) is absurdly remote to the point of non-e= xistence in practicality. >=20 > Brian >=20 > Sent from my iPhone >=20 > On Mar 2, 2011, at 6:53 PM, Bruce Atherton wrote: >=20 >> On 01/03/2011 6:58 AM, Andy Green wrote: >>> On 03/01/2011 02:40 PM, Somebody in the thread at some point said: >>>>=20 >>>> Being transported on a stream based protocol, it is screwed whenever it= >>>> misses the handshake as it cannot be sure where the frame starts even i= n >>>> the total absence of an asymmetric mask. If it has the handshake, then >>>> there is no problem, if it misses it then it has to apply a pile of >>>> heuristics - which still seems quite doable with masking (i.e. port >>>> numbers, testing likely bytes for known opcodes, testing them with the >>>> mask, etc..). >>>=20 >>> Well, you're right. >>>=20 >>> But two points ameliorate that, one is that the snooper only needs to ac= hieve sync at the start of its snooping session and it won't lose it again i= f it's genuinely synced. >>>=20 >>> The second point is the data on a websocket link is probably critical fo= r latency so it will try to issue what it has quite quickly, and likely burs= ty, so sometimes there's no traffic. If the server makes a new frame at a p= acket boundary you are very likely to find a websocket header at the start o= f the first network packet after a period of being idle. >>>=20 >>> If the data on the link doesn't fit that profile, eg it's audio that's a= lways coming at a fixed rate, but the server spilling packets is done at a s= maller amount of data than the frame length, yeah it'll be difficult to know= what you're looking at. >>>=20 >>=20 >> Exactly. You may have to scan a few packets before you find the start of a= frame, but it shouldn't be all that different from scanning an HTTP stream l= ooking for the beginning of a request or response. And if you know whether t= o unmask a particular set of packets or not, the heuristic for finding the s= tart of a frame becomes a lot easier to work with. This is especially true i= f you know what to look for in the particular payload types that are being s= ent (it could be XML, or fragments of audio data that you can try playing). >>=20 >> I would imagine that it won't be uncommon to turn off nagling of the pack= ets. Even when they are nagled, I would imagine it would be fairly common th= at a packet containing multiple frames would still start with a frame header= unless there was a continuous stream of small frames being sent. Also, that= people might choose smaller frame sizes even in applications with large mes= sage sizes to reduce the debugging burden as well as to reduce the latency o= f control messages. >>=20 >> As you say, once you have the start of one frame, you are golden and can d= etermine everything that comes afterward. But getting there is much easier i= f you can identify candidate packets for starting a frame without first unma= sking them (supporting Greg's proposal not to mask the frame) and if you don= 't need to test every candidate packet twice because the framing tells you w= hether masking is present or not. >>=20 >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi From duerst@it.aoyama.ac.jp Wed Mar 2 20:17:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330313A695B for ; Wed, 2 Mar 2011 20:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.846 X-Spam-Level: X-Spam-Status: No, score=-99.846 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfxM1kVMpvYg for ; Wed, 2 Mar 2011 20:17:06 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by core3.amsl.com (Postfix) with ESMTP id 95F593A6947 for ; Wed, 2 Mar 2011 20:17:06 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p234I4X8026797 for ; Thu, 3 Mar 2011 13:18:04 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 2e1a_62ab_3c69e384_454d_11e0_9d05_001d096c5782; Thu, 03 Mar 2011 13:18:04 +0900 Received: from [IPv6:::1] ([133.2.210.1]:58043) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 3 Mar 2011 13:18:05 +0900 Message-ID: <4D6EF7E3.2030508@it.aoyama.ac.jp> Date: Thu, 03 Mar 2011 11:07:31 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Greg Wilkins References: <23EC9206-34BB-454E-888F-4F41D4B24F9A@gmail.com> <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Hybi Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 04:17:08 -0000 Why not make the length of the data needed for a multiplexing extension (a multiple of) the length of the mask? That way, the actual payload data doesn't have to be touched at all. Regards, Martin. On 2011/03/02 14:24, Greg Wilkins wrote: > the whole point of this proposal is that things like multiplexers don't care > about the payload, but do care about framing and extension data. So if we > have masking in frame as an extension, then a multiplexer will be able to > take a masked payload, prepend some channel meta data and send in a new > frame, but without unmasking and remasking: > > > Client1->84L1M1M1M1M1P1..P1 > \ > MUX-> > 84L?C1C1M1M1M1M1P1..P184L?C2C2M2M2M2M2P2..P2->server > / > Client2->84L2M2M2M2M2P2...P2 > > > L? length > M? mask > C? mux channel > P? payload > > If we can do it this way, then the whole conversation about is XOR too > expensive for intermediaries goes away, because the intermediary does not > need to de-mask and re-mask. > > Note that this needs masking to be an extension, so that we can negotiate to > apply it after the MUX extension, otherwise the MUX channel data would need > to be masked and we would need to de-mask and re-mask. > > Note also that having masking an extension does not mean it does not have to > be mandatory. We can still insist that it is present in all negotiated > extension orderings if we want. > > cheers > > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Wed Mar 2 20:17:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323F73A6959 for ; Wed, 2 Mar 2011 20:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.85 X-Spam-Level: X-Spam-Status: No, score=-99.85 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8lhQ9Acl7ZH for ; Wed, 2 Mar 2011 20:17:06 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by core3.amsl.com (Postfix) with ESMTP id 960273A6951 for ; Wed, 2 Mar 2011 20:17:06 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p234I6PY026805 for ; Thu, 3 Mar 2011 13:18:06 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2da2_4164_3d3689b6_454d_11e0_bdcd_001d096c566a; Thu, 03 Mar 2011 13:18:06 +0900 Received: from [IPv6:::1] ([133.2.210.1]:58044) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 3 Mar 2011 13:18:06 +0900 Message-ID: <4D6F03A0.9010508@it.aoyama.ac.jp> Date: Thu, 03 Mar 2011 11:57:36 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John Tamplin References: <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 04:17:08 -0000 On 2011/03/02 15:25, John Tamplin wrote: > As for why you might want more than one, think about the way people use > browsers now. You probably have a number of tabs open, and a number of > long-running AJAX apps in some of them. Those apps periodically make > connections back to the server to check for new mail, poll for messages, Just checking, but isn't the main purpose of WebSockets to get rid of such checking/polling? The server can just send new mail notifications and messages to the client directly. Regards, Martin. > send user keystrokes, etc. The server would certainly prefer to have one > connection for all those apps in all those tabs (and you may have modular > apps such that one tab may have multiple connections). If many of these > messages are small, network utilization would be much better if the small > messages were aggregated into one larger message (of course there is a > latency trade-off here). Likewise, intermediaries for bandwidth-constrained > networks (such as VPN crossing the public internet or perhaps some mobile > network configurations) will also have interest in aggregating small frames. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From andy.warmcat.com@googlemail.com Thu Mar 3 00:45:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432613A68B3 for ; Thu, 3 Mar 2011 00:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlVjfyu9l6XO for ; Thu, 3 Mar 2011 00:45:41 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E28CA3A68AF for ; Thu, 3 Mar 2011 00:45:40 -0800 (PST) Received: by wwb22 with SMTP id 22so782978wwb.13 for ; Thu, 03 Mar 2011 00:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FRf7dG2Wze/AqvlSsM7eCAyidCpA/hTe5LItvwbU4gg=; b=lZPOT/+r9RW0DMa41lwU6y8F+RS5wJeNGjmCpvG0utWbyX5k7YAOXmZCB3kTRF5spp PfdUc9LNE4aSyVpJJp8C+F3zMz4fvJXo3/uEEKHbLMGt9YonWa4o3pON0szsHvydnVDj 8YyPprTt5FSAZZZj1Avawvew77AbxWKOC10Ls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=baR2daoNYtLVGaHfWM+QUlnUz4noNNgDJc4+7FgzS01u9skecRHjMEMlIrNrbqUQ7e DeujTxXhRi+3ui7HL8NcIVfQnAHkK5L03B0PpbKI5U9JXcVFBaJ8DorxLpziPv08LFiN vpJdr5PiLgYAmVJSwdP2Iu5FU4ks0rV6Tv3rM= Received: by 10.227.196.65 with SMTP id ef1mr629023wbb.158.1299142007342; Thu, 03 Mar 2011 00:46:47 -0800 (PST) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id y29sm703704wbd.10.2011.03.03.00.46.43 (version=SSLv3 cipher=OTHER); Thu, 03 Mar 2011 00:46:44 -0800 (PST) Sender: Andy Green Message-ID: <4D6F5571.9090806@warmcat.com> Date: Thu, 03 Mar 2011 08:46:41 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <30DBC9B6-A495-4CD9-8CBF-E79FD713B1D2@gmail.com> <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> <4D6F03A0.9010508@it.aoyama.ac.jp> In-Reply-To: <4D6F03A0.9010508@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 08:45:42 -0000 On 03/03/2011 02:57 AM, Somebody in the thread at some point said: > On 2011/03/02 15:25, John Tamplin wrote: > >> As for why you might want more than one, think about the way people use >> browsers now. You probably have a number of tabs open, and a number of >> long-running AJAX apps in some of them. Those apps periodically make >> connections back to the server to check for new mail, poll for messages, > > Just checking, but isn't the main purpose of WebSockets to get rid of > such checking/polling? The server can just send new mail notifications > and messages to the client directly. You're right, but once these TCP connections "go quiet" as part of lack of polling, there's a new issue of the ambiguity of silence. Is it truly because nobody had any new event, or because an endpoint or intermediary's Ethernet cable fell out, mobile entered a cell with dead internet, etc. So there'll be a common need to require a background noise of traffic at long intervals to confirm the connection is still live and CAN issue events still. -Andy From Yutaka_Takeda@PlayStation.Sony.Com Thu Mar 3 02:51:55 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 964543A69B7 for ; Thu, 3 Mar 2011 02:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOsTFF5Fn7kT for ; Thu, 3 Mar 2011 02:51:53 -0800 (PST) Received: from paris.playstation.sony.com (nat.playstation.sony.com [69.36.131.254]) by core3.amsl.com (Postfix) with ESMTP id CD1053A69B5 for ; Thu, 3 Mar 2011 02:51:53 -0800 (PST) Received: from constantine.playstation.sony.com ([162.49.67.15]) by paris.playstation.sony.com (Lotus Domino Release 8.5.1FP5) with ESMTP id 2011030302525962-6195 ; Thu, 3 Mar 2011 02:52:59 -0800 In-Reply-To: To: Greg Wilkins MIME-Version: 1.0 X-KeepSent: C567FA30:A293E81E-88257848:0032D3CC; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Yutaka_Takeda@PlayStation.Sony.Com Date: Thu, 3 Mar 2011 02:57:16 -0800 X-MIMETrack: Serialize by Router on SCEA919ML04/SCEA(Release 8.5.1FP3|May 23, 2010) at 03/03/2011 02:52:59 AM, Serialize complete at 03/03/2011 02:52:59 AM, Itemize by SMTP Server on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/03/2011 02:52:59 AM, Serialize by Router on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/03/2011 02:53:01 AM, Serialize complete at 03/03/2011 02:53:01 AM Content-Type: multipart/alternative; boundary="=_alternative 003C2DC688257848_=" Cc: Hybi Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 10:51:55 -0000 This is a multipart message in MIME format. --=_alternative 003C2DC688257848_= Content-Type: text/plain; charset="US-ASCII" o Masked framing vs mask in frame (original discussion point) I give +1 for masking inside frame (payload). I agree with what Greg has being pointing out over and over in this thread particularly in preventing intermediaries from having to mask/demask frames for better scalability. o Extension field length It was not clear to me whether understanding the extension field was required to parse real payload. If the extension is intended to be required to correctly parse payload, then I will give +1 for making extension also, which makes the need of extension length less important. One suggestion: There were many other points being discussed in this thread it was a bit hard to follow. One thing I realized as I was reading this thread was that there were two essentially separated aspects of protocol design totally mixed in this discussion. One is protocol "layering" (where to mask, etc.) and protocol between specific entities (e.g. extensions). I believe when we design protocols, we need first to; Phase 1: Define layers (who you are talking to and what their rols are, etc.), and then; Phase 2: Define protocol details between the same layer entities. >From what I can see, WS protocol seems to already have at least following layer entities and intermediaries: [ App. ]<------------------------------------------------------->[ App. ] [ deflate ]<-------------------------------------->[ deflate ]<---->[ deflate ] (optional) [ Ext. ]<-------------------------------------->[ Ext. ]<---->[ Ext. ] (optional) [ Masking ]<-------------------------------------->[ Masking ]<---->[ Masking ] (C->S only) [ Framing ]<--------------------->[ Framing ]<---->[ Framing ]<---->[ Framing ] [ TCP ]<---->[ TCP ]<---->[ TCP ]<---->[ TCP ]<---->[ TCP ] Client Std Proxy WS-aware proxy App.Lvl GW Server \............. Intermediaries ............./ I think it is important to define some thing like above first. This defines not only the sub layers of WebSocket protocol, but also types of intermediaries, roles of each protocol entities, the order of in/outbound processes (outbound goes downwards through layers, and the other way for inbound, needless to say). Then we start defining how each entities (each '<------>' lines) communicate with each other (sub-layer protocols). Once we complete this, further issues are mostly localized within the sub-protocol and our discussion will be focused and smoother, rather than suddenly turning upside down all over layers again in the middle of discussing details of the protocol, which seems to be happening in the discussion in this thread(and others) and taking longer time than necessary to come to consensus. Defined notion of sub-protocols and terminology in phase 1 would help our smooth discussion a lot, too. "Do we need a light-weight WS-aware proxy?" seems to be a good start without looking at headers from the beginning, for example. # this is also relevant to discussion in another thread about what to deflate: http://www.ietf.org/mail-archive/web/hybi/current/msg06352.html Again, deflate extension should be right below the app layer, IMO... my two cents - Yutaka hybi-bounces@ietf.org wrote on 03/01/2011 11:05:42 PM: > On 2 March 2011 17:25, John Tamplin wrote: > > > And then they would have to unmask the client frames, which is > what I thought you were trying to avoid > > I was responding to your example where MUX is done in browser and > there is no intermediary. I'm concerned about intermediaries having > to demask just to know where the framing boundaries are - and not just > (or even) because of performance. > > If browser are doing the muxing, then there is not an issue. Of > course it is still possible for an intermediary to the MUX the already > MUXed connection from the browser, in which case it would be desirable > for it to not have to demask the frames in order to do it's work. > > > > > Right, if there is only one logical frame inside the MUXed frame > you don't have to remask anything anyway, so I assumed the > discussion was about when you had more than one. > > Well even with 1, the intermediary has to demask because the frame is masked. > OK, it does not need to demask the entire frame and it can reuse the > mask on the outbound connection so it can just copy over the payload > after the variable length length fields..... but that is really rather > ugly and a real violation of layered protocols. Essentially the > intermediaries are gaming the mask algorithm. > > > > > As for why you might want more than one, think about the way > people use browsers now. You probably have a number of tabs open, > and a number of long-running AJAX apps in some of them. Those apps > periodically make connections back to the server to check for new > mail, poll for messages, send user keystrokes, etc. The server > would certainly prefer to have one connection for all those apps in > all those tabs (and you may have modular apps such that one tab may > have multiple connections). If many of these messages are small, > network utilization would be much better if the small messages were > aggregated into one larger message (of course there is a latency > trade-off here). > > Really? will the network really care if the TCP/IP packet contains 1 > aggregate WS frame or several individual frames? > > > > I think it is going to be hard to convince browser vendors that > some part of the frame, including extension data that hasn't been > invented yet, is safe to leave unmasked. I think it is feasible to > have the option available and have browsers enforce it the way they want it, > > I'm not trying to convince browser vendors to include extension data > that is either unmasked or not invented yet. Browser vendors are > free to insist that masking is the mandatory first extension using a > good mask generator - so all data is masked and that is not optional. > > I don't think we should be running scared about what browser vendors > may or may not accept. They have expressed requirements that they > want mandatory masking and I think my proposal allows them to have > that. > > > > > but that idea doesn't seem to be getting much traction. > > I have seen several voices in support. > > The voices in opposition appear to have miss understood the proposal > and are saying that they want mandatory masking (which can be done) or > that XOR is cheap (which it mostly is and this proposal is not > motivated by the expense of masking). > > > cheers > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --=_alternative 003C2DC688257848_= Content-Type: text/html; charset="US-ASCII"
o Masked framing vs mask in frame (original discussion point)

I give +1 for masking inside frame (payload). I agree with what Greg has being pointing out
over and over in this thread particularly in preventing intermediaries from having to mask/demask
frames for better scalability.

o Extension field length

It was not clear to me whether understanding the extension field was required to parse real
payload. If the extension is intended to be required to correctly parse payload, then I will
give +1 for making extension also, which makes the need of extension length less important.


One suggestion:

There were many other points being discussed in this thread it was a bit hard to follow. One
thing I realized as I was reading this thread was that there were two essentially separated
aspects of protocol design totally mixed in this discussion. One is protocol "layering"
(where to mask, etc.) and protocol between specific entities (e.g. extensions).

I believe when we design protocols, we need first to;

Phase 1:  Define layers (who you are talking to and what their rols are, etc.),

and then;

Phase 2:  Define protocol details between the same layer entities.

From what I can see, WS protocol seems to already have at least following layer entities and intermediaries:

[   App.  ]<------------------------------------------------------->[   App.  ]
[ deflate ]<-------------------------------------->[ deflate ]<---->[ deflate ] (optional)
[   Ext.  ]<-------------------------------------->[   Ext.  ]<---->[   Ext.  ] (optional)
[ Masking ]<-------------------------------------->[ Masking ]<---->[ Masking ] (C->S only)
[ Framing ]<--------------------->[ Framing ]<---->[ Framing ]<---->[ Framing ]
[   TCP   ]<---->[   TCP   ]<---->[   TCP   ]<---->[   TCP   ]<---->[   TCP   ]

   Client          Std Proxy     WS-aware proxy    App.Lvl GW         Server
                  \.............  Intermediaries ............./

I think it is important to define some thing like above first. This defines not only the sub layers of
WebSocket protocol, but also types of intermediaries, roles of each protocol entities, the order
of in/outbound processes (outbound goes downwards through layers, and the other way for inbound,
needless to say). Then we start defining how each entities (each '<------>' lines) communicate
with each other (sub-layer protocols). Once we complete this, further issues are mostly localized
within the sub-protocol and our discussion will be focused and smoother, rather than suddenly turning
upside down all over layers again in the middle of discussing details of the protocol,
which seems to be happening in the discussion in this thread(and others) and taking longer time
than necessary to come to consensus. Defined notion of sub-protocols and terminology in phase 1
would help our smooth discussion a lot, too.

"Do we need a light-weight WS-aware proxy?" seems to be a good start without looking at headers
from the beginning, for example.

# this is also relevant to discussion in another thread about what to deflate:
http://www.ietf.org/mail-archive/web/hybi/current/msg06352.html
Again, deflate extension should be right below the app layer, IMO...


my two cents

- Yutaka




hybi-bounces@ietf.org wrote on 03/01/2011 11:05:42 PM:

> On 2 March 2011 17:25, John Tamplin <jat@google.com> wrote:
>
> > And then they would have to unmask the client frames, which is
> what I thought you were trying to avoid
>
> I  was responding to your example where MUX is done in browser and
> there is no intermediary.   I'm concerned about intermediaries having
> to demask just to know where the framing boundaries are - and not just
> (or even) because of performance.
>
> If browser are doing the muxing, then there is not an issue.     Of
> course it is still possible for an intermediary to the MUX the already
> MUXed connection from the browser, in which case it would be desirable
> for it to not have to demask the frames in order to do it's work.
>
>
>
> > Right, if there is only one logical frame inside the MUXed frame
> you don't have to remask anything anyway, so I assumed the
> discussion was about when you had more than one.
>
> Well even with 1, the intermediary has to demask  because the frame is masked.
> OK, it does not need to demask  the entire frame and it can reuse the
> mask on the outbound connection so it can just copy over the payload
> after the variable length length fields..... but that is really rather
> ugly and a real violation of layered protocols.  Essentially the
> intermediaries are gaming the mask algorithm.
>
>
>
> > As for why you might want more than one, think about the way
> people use browsers now.  You probably have a number of tabs open,
> and a number of long-running AJAX apps in some of them.  Those apps
> periodically make connections back to the server to check for new
> mail, poll for messages, send user keystrokes, etc.  The server
> would certainly prefer to have one connection for all those apps in
> all those tabs (and you may have modular apps such that one tab may
> have multiple connections).  If many of these messages are small,
> network utilization would be much better if the small messages were
> aggregated into one larger message (of course there is a latency
> trade-off here).
>
> Really? will the network really care if the TCP/IP packet contains 1
> aggregate WS frame or several individual frames?
>
>
> > I think it is going to be hard to convince browser vendors that
> some part of the frame, including extension data that hasn't been
> invented yet, is safe to leave unmasked.  I think it is feasible to
> have the option available and have browsers enforce it the way they want it,
>
> I'm not trying to convince browser vendors to include extension data
> that is either unmasked or not invented yet.   Browser vendors are
> free to insist that masking is the mandatory first extension using a
> good mask generator - so all data is masked and that is not optional.
>
> I don't think we should be running scared about what browser vendors
> may or may not accept.  They have expressed requirements that they
> want mandatory masking and I think my proposal allows them to have
> that.
>
>
>
> > but that idea doesn't seem to be getting much traction.
>
> I have seen several voices in support.
>
> The voices in opposition appear to have miss understood the proposal
> and are saying that they want mandatory masking (which can be done) or
> that XOR is cheap (which it mostly is and this proposal is not
> motivated by the expense of masking).
>
>
> cheers
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
 --=_alternative 003C2DC688257848_=-- From jamie@shareable.org Thu Mar 3 07:15:27 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2577A3A67B2 for ; Thu, 3 Mar 2011 07:15:27 -0800 (PST) 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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXtgfGlQPcbj for ; Thu, 3 Mar 2011 07:15:26 -0800 (PST) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 3AF9B3A67B1 for ; Thu, 3 Mar 2011 07:15:26 -0800 (PST) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1PvAGT-0007jX-Rc; Thu, 03 Mar 2011 15:16:29 +0000 Date: Thu, 3 Mar 2011 15:16:29 +0000 From: Jamie Lokier To: Brodie Thiesfield Message-ID: <20110303151629.GA29234@shareable.org> References: <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 15:15:27 -0000 Brodie Thiesfield wrote: > Of course, servers cannot force clients to use a zero or non-zero > mask. That is always going to be the responsibility of the client. Servers can _easily_ force clients to use a non-zero, varying mask - by looking at the mask, and if it's consistently the same for several frames in a row, reject the connection. Servers may actually do that, if they think it blocks some kind of attack - or even if they just want to slightly deter connections from casually written non-browser clients. -- Jamie From jamie@shareable.org Thu Mar 3 08:39:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3862B3A68B9 for ; Thu, 3 Mar 2011 08:39:39 -0800 (PST) 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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y41-mazQAgW1 for ; Thu, 3 Mar 2011 08:39:38 -0800 (PST) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id A064B3A67F1 for ; Thu, 3 Mar 2011 08:39:37 -0800 (PST) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1PvBZt-0008HV-RM; Thu, 03 Mar 2011 16:40:37 +0000 Date: Thu, 3 Mar 2011 16:40:37 +0000 From: Jamie Lokier To: Greg Wilkins Message-ID: <20110303164037.GC29234@shareable.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 16:39:39 -0000 Greg Wilkins wrote: > Declaring that the protocol MUST send ping/pongs at that rate would be > half baked. First, if any of you find this mail too long, please skip to the last paragraph, which is actually the most important. Summary: the client Javascript needs to know the timeout of its *own* WebSocket to do client-initiated ping/pong, and your header puts the information in the wrong place for that. Back to keepalives. Compared with two-way idle keepalives, ping/pongs are: (a) Wasteful of bandwidth (you don't need keepalive messages in both directions if one direction is actively moving data, but you still need keepalive in one direction - if the data sending side needs to detect a dead connection quickly.) (b) Overly sensitive to network latency variance (you have to subtract latency variance _twice_ from the timeouts to get the sending rate with ping/pongs). (c) Unnecessarily symmetric (the server may not care if the connection is gone for a few minutes, but the client probably wants to know ASAP, so it can launch a new connection. That can approximately halve the number of keepalive messages. But in some applications, the server needs to know ASAP, so it can register that a client is offline on some status screen) (d) Not really simpler to implement than independent two-way idle keepalives, because you need a timeout mechanism at both ends in both cases anyway, and other factors as described below. The only thing ping/pong has going for it, imho, is everyone thinks they know what is intended by it. But...? That isn't actually clear: Does ping/pong mean send a ping every N seconds, or only after N seconds of idleness? If it means _every_ N seconds, if the connection is saturated with real data, the ping or pong may be delayed by the data, leading to "false timeout" even though the connection is working perfectly. If idleness, there a few questions about what is idleness, when large messages and/or full sending buffers happen. And _who_ sends the ping - client or server? Inside a browser it is even more exciting: the browser has to keep reading and queuing messages for Javascript, even if the Javascript is unable to keep up or busy with something else, and cannot bound the memory used by simply pausing TCP, if pings must be read and responded to quickly. So there's a potential browser memory DOS side effect. > It is probably too hard for us to achieve consensus for a keep alive > mechanism in the protocol itself, but that declared timeouts would be > a good first step towards a standard keep alive mechanism. Only if the *meaning* of those timeouts is specified. If a client says its timeout is 45s, but the acceptable network latency variance is 5s, the server needs to transmit something every 40s to keep connected. At the same time, if the server says its timeout is 180s, the client needs to transmit something every 175s seconds to keep the server happy. But if it's PING/PONG, then the client needs to transmit PING every 35s to keep the connection going. The difference between 175s and 35s is significant, yet both are derived from the proposed timeout values - depending on the timeout mechanism in use. So not only the values matter - how they will be used matters. > Failing a standard keep alive mechanism, frameworks and applications > will have to implement their own keep alives - websocket applications > will just not work without them! Yes. Ian Hixie's tiny "tic-tac-toe" example suffers from this. It locks up on some networks if you don't make a move for a minute or two. > If you are really worried about the bytes - then we could define > control packets to query configuration parameters, but that sounds > like a lot more faff than just > > Sec-WebSocket-IdleTimeout: 200s I think the more important thing is to define what that 200s actually means. Does the other end need to ensure it sends: (a) start of a message every 200s (minus network latency), (b) _any part_ of a message every 200s (minus network latency), (that matters when there are large messages, which may take a while to send), (c) an explicit "ping" every 200s (minus network latency twice for RTT), (d) an explicit "keepalive" every 200s (minus network latency), (e) an explicit TCP event every 200s (minus network latency), > If we provide a standard way for timeouts to be declared, then at > least on the server side, that information can be used to guide the > frameworks and applications in choosing a frequency (which may still > prove to be wrong due to intermediaries, but that is valuable > information to know and at least the framework could start any backoff > strategy at a realistic timeout). I think if the applications are performing keepalive _itself_ - then its up to the applications how they declare the keepalive parameters _and_ what keepalive method they are using. My applications *won't* use ping/pong for their keepalive, if it's avoidable. But the added wrinkle is we have application timeouts *and* WebSocket implementation timeouts below the application. It's quite a messy laying violation, but also unavoidable as long as both the application and the WebSocket implementation below it both have to implement timeout mechanisms - possibly different ones. What I would really dislike is if an application has to keep sending redundant empty messages over the net to keep the WebSocket *implementation* at the other end happy, even though the application at the other end knows the connection is working fine - just because the application has no API to tell its own WebSocket that the connection is still running fine. Which brings me to something you haven't suggested: The proposed Sec-WebSocket-IdleTimeout: tells the _other_ end what timeout the generic WebSocket will use at this end. But how does _this_ end's application learn what its own WebSocket's timeout is? That information is crucial: You can't PING/PONG from the client Javascript unless you know the client-side WebSocket timeout, and your Sec-WebSocket-IdleTimeout header *does not give that value to the code which needs it*. So real applications will have to receive it on the server, and then send it in an application-specific control message back to the client *anyway*. The correct place for it is in API that the local Javascript can read, and maybe change, but nobody dares add to the API. -- Jamie From jat@google.com Thu Mar 3 08:51:29 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED253A67F1 for ; Thu, 3 Mar 2011 08:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.805 X-Spam-Level: X-Spam-Status: No, score=-105.805 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUU4nSjhO1hL for ; Thu, 3 Mar 2011 08:51:28 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 8CD8C3A6841 for ; Thu, 3 Mar 2011 08:51:28 -0800 (PST) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p23GqY8W004179 for ; Thu, 3 Mar 2011 08:52:35 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299171155; bh=Mb3NpWC88NoVGxvQeZH0wVbXHD8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Y1WBDvvVAqtQ6c6oWPivJfZCy+fSmcEyzu3p6W9EobfdKL4T802Pb5Kej+MP6DbdK Wt3xXq0rwSbAvsHuSinmA== Received: from ywl41 (ywl41.prod.google.com [10.192.12.41]) by kpbe17.cbf.corp.google.com with ESMTP id p23GqPEe006166 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 3 Mar 2011 08:52:33 -0800 Received: by ywl41 with SMTP id 41so568116ywl.18 for ; Thu, 03 Mar 2011 08:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oLJeq97yfMCkGGNNuZqMvQYEXc8NWYui4kbNGpcTXwI=; b=KKfYprHxdRGs+tVHTsByFOdSdJoGHqbImruAo6MGo55fk1RsJYzBFPTX0MLUI+bevN t3P8miK/4bqQefF0jSZw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=bG5KsQHgt3l6SwEn7z6d+Kz8Uui/m0Z94HgP4QcCSijV2NgqsegXbX69BAORLgpo1S Nw/1c3iZmYJTNZQtpX+g== Received: by 10.150.149.16 with SMTP id w16mr2043655ybd.217.1299171153124; Thu, 03 Mar 2011 08:52:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Thu, 3 Mar 2011 08:52:13 -0800 (PST) In-Reply-To: <20110303164037.GC29234@shareable.org> References: <20110303164037.GC29234@shareable.org> From: John Tamplin Date: Thu, 3 Mar 2011 11:52:13 -0500 Message-ID: To: Jamie Lokier Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" , Greg Wilkins Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 16:51:29 -0000 When we first discussed Ping/Pong frames, my recollection was that we were specifically not trying to decide on how heartbeat/keep-alive/idle timeout/etc would be implemented, but rather just providing a facility similar to ICMP ECHO at the WebSocket layer for diagnostics and perhaps future use for such things. My question is: do we really need to decide on heartbeat/keep-alive/idle-timeouts etc now, or can we ship the protocol without it (knowing that means applications will build their own facility on top of it) and then later add it to the protocol when we have actual usage data to look at to help drive consensus? My preference would be to keep the protocol simple now and add it later, in the interest of getting something out soon. However, if the consensus is that the base protocol must include this functionality, then we have a lot more work to do including discussions like this. -- John A. Tamplin Software Engineer (GWT), Google From godjonez@codepad.info Thu Mar 3 09:03:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EA2E3A69FD for ; Thu, 3 Mar 2011 09:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3U5HsO0EbavK for ; Thu, 3 Mar 2011 09:03:23 -0800 (PST) Received: from smtpout.kotinet.com (smtpout.kotinet.com [212.50.215.76]) by core3.amsl.com (Postfix) with ESMTP id 163293A69FC for ; Thu, 3 Mar 2011 09:03:23 -0800 (PST) Received: from codepad.info (codepad.info [62.240.71.135]) by smtpout.kotinet.com (Postfix) with ESMTP id 0D7EE47714; Thu, 3 Mar 2011 19:04:17 +0200 (EET) Received: from overwatchnexus.combinet (overwatchnexus.combinet [192.168.2.7]) by codepad.info (Postfix) with ESMTPSA id 68BFFF44003; Thu, 3 Mar 2011 19:04:16 +0200 (EET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Jamie Lokier" , "John Tamplin" References: <20110303164037.GC29234@shareable.org> Date: Thu, 03 Mar 2011 19:04:19 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Joonas Lehtolahti" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.10 (Win32) Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" , Greg Wilkins Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 17:03:24 -0000 On Thu, 03 Mar 2011 18:52:13 +0200, John Tamplin wrote: > When we first discussed Ping/Pong frames, my recollection was that we > were specifically not trying to decide on how > heartbeat/keep-alive/idle timeout/etc would be implemented, but rather > just providing a facility similar to ICMP ECHO at the WebSocket layer > for diagnostics and perhaps future use for such things. > > My question is: do we really need to decide on > heartbeat/keep-alive/idle-timeouts etc now, or can we ship the > protocol without it (knowing that means applications will build their > own facility on top of it) and then later add it to the protocol when > we have actual usage data to look at to help drive consensus? > > My preference would be to keep the protocol simple now and add it > later, in the interest of getting something out soon. However, if the > consensus is that the base protocol must include this functionality, > then we have a lot more work to do including discussions like this. > I agree with this. The protocol should IMO just state how to handle incoming Ping message (reply with Pong), but doesn't need any statement on actually using them. If a client or a server wants to use them, it can decide to send them when it sees it as proper and act as it wishes for not receiving pong message in whatever timeout value it desires to use. This would also include the liberty of choosing whether to expose Ping/Pong to application from the websocket framework or not. For web browsers that question would of course be delegated to the Websockets API working group, for non-browser applications the exact implementation is a concern for only that application's developer and therefore they have free hands to use ping (or not use it) anyway they wish, unless limited in the websockets protocol specification. And I think the usage shouldn't be mandated. Other might have (and do have) differing opinions... From dendicott@gmail.com Thu Mar 3 09:06:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1CEE3A6A07 for ; Thu, 3 Mar 2011 09:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmyxL-F+nGNO for ; Thu, 3 Mar 2011 09:06:21 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 61A5F3A67F1 for ; Thu, 3 Mar 2011 09:06:21 -0800 (PST) Received: by wyb42 with SMTP id 42so1364106wyb.31 for ; Thu, 03 Mar 2011 09:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Pdm1O4OWWOlolUdpmzZ7tL6x2XxCf9QsGvkyq72aUvs=; b=bQwyRnenhoF6Tf7kgcf4tmiqa/tlvBRvQQyaLfdrU7JWd45D/g9kHI0TVBmRJEZT9U xh7rr/KOUnytIhDhCYBoCTYLgJlaj24ToUfKOdP5v3ybXDK4YhFL/6u1YTg9gnbulPG5 mvChm946IuWbJSm9BhF1BFa826FKump8H068M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Fmwog0c56WVqf9bQYsnrMnIHjg+MG+ZLAgz8VLMwJxrLjXr+6WVa0aZTzswyEhbD9t 8kaW17r4WkizVKu8AXmuVam8iTHk1EFkr+6Asqr4tZp1iImtv5cU+i9BGKixYnlT3PzQ 26ZrGshXFzHeCLgIHwLHcipIFbu4w1G+lwO+k= MIME-Version: 1.0 Received: by 10.216.181.76 with SMTP id k54mr852365wem.58.1299172047928; Thu, 03 Mar 2011 09:07:27 -0800 (PST) Received: by 10.217.1.84 with HTTP; Thu, 3 Mar 2011 09:07:27 -0800 (PST) In-Reply-To: References: <20110303164037.GC29234@shareable.org> Date: Thu, 3 Mar 2011 12:07:27 -0500 Message-ID: From: David Endicott To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" , Greg Wilkins Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 17:06:22 -0000 My understanding is that websocket is a "framed" transport protocol sitting on top of TCP. I am already uncomfortable with Ping/Pong frames (not to mention "Hello") as I view that functionality as properly belonging to a higher application layer. I see no good reason to introduce application layer mechanisms (time-outs, heartbeats, etc.) into a transport layer protocol. My vote is to exclude it as being outside the proper scope of this protocol= . On Thu, Mar 3, 2011 at 11:52 AM, John Tamplin wrote: > When we first discussed Ping/Pong frames, my recollection was that we > were specifically not trying to decide on how > heartbeat/keep-alive/idle timeout/etc would be implemented, but rather > just providing a facility similar to ICMP ECHO at the WebSocket layer > for diagnostics and perhaps future use for such things. > > My question is: =A0do we really need to decide on > heartbeat/keep-alive/idle-timeouts etc now, or can we ship the > protocol without it (knowing that means applications will build their > own facility on top of it) and then later add it to the protocol when > we have actual usage data to look at to help drive consensus? > > My preference would be to keep the protocol simple now and add it > later, in the interest of getting something out soon. =A0However, if the > consensus is that the base protocol must include this functionality, > then we have a lot more work to do including discussions like this. > > -- > John A. Tamplin > Software Engineer (GWT), Google > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From ferg@caucho.com Thu Mar 3 09:17:10 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7354C3A69FC for ; Thu, 3 Mar 2011 09:17:10 -0800 (PST) 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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5EG4I0LbTPV for ; Thu, 3 Mar 2011 09:17:09 -0800 (PST) Received: from nm29.bullet.mail.ac4.yahoo.com (nm29.bullet.mail.ac4.yahoo.com [98.139.52.226]) by core3.amsl.com (Postfix) with SMTP id 7A5633A67F1 for ; Thu, 3 Mar 2011 09:17:09 -0800 (PST) Received: from [98.139.52.188] by nm29.bullet.mail.ac4.yahoo.com with NNFMP; 03 Mar 2011 17:18:17 -0000 Received: from [98.139.52.132] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 03 Mar 2011 17:18:17 -0000 Received: from [127.0.0.1] by omp1015.mail.ac4.yahoo.com with NNFMP; 03 Mar 2011 17:18:17 -0000 X-Yahoo-Newman-Id: 159303.74152.bm@omp1015.mail.ac4.yahoo.com Received: (qmail 55725 invoked from network); 3 Mar 2011 17:18:17 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 03 Mar 2011 09:18:16 -0800 PST X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: Azcif0sVM1nftW_l4_T0WJoqPiBvNShUjmfgTV8Wv1J.PXZ 15IxJ0bPcbQdscTdl.VEbmuuktGKjsXCjosXQtrsfxnpJCr18BPmMzuFNWZv Y8.YVATWARR7tGuWz7nw6aMV6YG7JXKGd1aqmbjBE1p_oMhgWHDNZSAdycgP M6zcjdFte.SF9kMoBSoV5p6NbYPLAgw.VfSXXAVMEzx4WKlpx2LaAM0i5ArE 1G49jlZgKEurmrn6inGfN.D6c.5s- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D6FCD43.4000409@caucho.com> Date: Thu, 03 Mar 2011 09:17:55 -0800 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <20110303164037.GC29234@shareable.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 17:17:10 -0000 On 03/03/2011 08:52 AM, John Tamplin wrote: > When we first discussed Ping/Pong frames, my recollection was that we > were specifically not trying to decide on how > heartbeat/keep-alive/idle timeout/etc would be implemented, but rather > just providing a facility similar to ICMP ECHO at the WebSocket layer > for diagnostics and perhaps future use for such things. > > My question is: do we really need to decide on > heartbeat/keep-alive/idle-timeouts etc now, or can we ship the > protocol without it (knowing that means applications will build their > own facility on top of it) and then later add it to the protocol when > we have actual usage data to look at to help drive consensus? > > My preference would be to keep the protocol simple now and add it > later, in the interest of getting something out soon. However, if the > consensus is that the base protocol must include this functionality, > then we have a lot more work to do including discussions like this. Should the following be removed from 4.5.3 "Pong", following that line of thinking? A Pong is issued only in response to the most recent Ping. Otherwise, the spec is making a decision against unidirectional keepalives. There's also the option of pushing ping/pong to an extension if more time/experience is needed to get the definition right. -- Scott From bruce@callenish.com Thu Mar 3 09:24:43 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571013A6A02 for ; Thu, 3 Mar 2011 09:24:43 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7U+ISCgfWOw for ; Thu, 3 Mar 2011 09:24:42 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 8DC843A67F1 for ; Thu, 3 Mar 2011 09:24:42 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.103]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1PvCHa-0000dE-2l; Thu, 03 Mar 2011 09:25:46 -0800 Message-ID: <4D6FCF1C.3090701@callenish.com> Date: Thu, 03 Mar 2011 09:25:48 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: John Tamplin References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Cc: "hybi@ietf.org" , Gabriel Montenegro Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 17:24:43 -0000 On 02/03/2011 11:13 AM, John Tamplin wrote: > My suggestion would be to define a CONTROL opcode, and then for that > opcode the first byte of the payload defines which control frame is > present. +1. Simply from a design perspective it makes more sense. Text frame, binary frame, continuation frame, and control frame all feel like the same level of abstraction. Breaking control down into ping, pong, and close seems like an abstraction imbalance. And what do you gain by taking this deep-dive on the control frames? Saving a single byte from a frame that is already tiny? Plus there are the other benefits you mention. I just think this makes sense. From Gabriel.Montenegro@microsoft.com Thu Mar 3 09:25:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD773A69FF for ; Thu, 3 Mar 2011 09:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvt23pueI0dl for ; Thu, 3 Mar 2011 09:25:27 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B9DBD3A6830 for ; Thu, 3 Mar 2011 09:25:27 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Mar 2011 09:26:35 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.270.2; Thu, 3 Mar 2011 09:26:35 -0800 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.139]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Thu, 3 Mar 2011 09:26:34 -0800 From: Gabriel Montenegro To: Scott Ferguson , "hybi@ietf.org" Thread-Topic: [hybi] Hello frames? Thread-Index: AQHL14412iWCpzy4ZUaGhFQV7JGbhJQXiymQgACrhQCAAE0vgIAAA14AgABt9ICAACx7gIAAZ7gAgAAT+ACAAAKrgIAACiAAgAAFsICAAAdbgIAAAh6AgAAEzoCAAAE4gIAAClCAgAKQzoCAAAM+gIAABy6A//97lCA= Date: Thu, 3 Mar 2011 17:26:34 +0000 Message-ID: References: <20110303164037.GC29234@shareable.org> <4D6FCD43.4000409@caucho.com> In-Reply-To: <4D6FCD43.4000409@caucho.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 17:25:28 -0000 > Should the following be removed from 4.5.3 "Pong", following that line of > thinking? >=20 > A Pong is issued only in response to the most recent Ping. >=20 >=20 > Otherwise, the spec is making a decision against unidirectional keepalive= s. [gab] Unidirectional keepalives were not originally discussed, so I would l= ist them as stuff to be done afterwards. I would much rather we keep the ba= sic Ping/Pong as in the spec, with the above which simplifies the implement= ation a lot (and provides one element of a rudimentary but effective DoS pr= otection). > There's also the option of pushing ping/pong to an extension if more > time/experience is needed to get the definition right. [gab] Given that it's been there for a long time, in the interest of having= a simple spec soon, I'd rather we kept it as is, but postpone further refi= nements, timeouts etc for later. From ferg@caucho.com Thu Mar 3 09:40:05 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74CC3A690F for ; Thu, 3 Mar 2011 09:40:04 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3+lFiMVCXfe for ; Thu, 3 Mar 2011 09:40:02 -0800 (PST) Received: from nm1-vm0.bullet.mail.ac4.yahoo.com (nm1-vm0.bullet.mail.ac4.yahoo.com [98.139.53.202]) by core3.amsl.com (Postfix) with SMTP id 77B7D3A6860 for ; Thu, 3 Mar 2011 09:40:01 -0800 (PST) Received: from [98.139.52.190] by nm1.bullet.mail.ac4.yahoo.com with NNFMP; 03 Mar 2011 17:41:04 -0000 Received: from [98.139.52.141] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 03 Mar 2011 17:41:04 -0000 Received: from [127.0.0.1] by omp1024.mail.ac4.yahoo.com with NNFMP; 03 Mar 2011 17:41:04 -0000 X-Yahoo-Newman-Id: 513883.85169.bm@omp1024.mail.ac4.yahoo.com Received: (qmail 16999 invoked from network); 3 Mar 2011 17:41:03 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 03 Mar 2011 09:41:03 -0800 PST X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: Lt3ko88VM1n.NZe_lUwKK7l5kV0_udzQP9k1b4wdhyxXFrn T8N9v916F.ItvOfwFGXzwG16JsSCiXS1Bl_k9xtmljDOLkzvbiCPisVHQCgB ndHednfW4wogOvE3i3G3GiGmL0AhMSniQZnxqQCNvyS1D6njGHt.nxfAb.Uc DKEQlYswJ0nXmrx8wX1R9z4uGTPDyw.xWlReRHwVMv8j3gHQ6y05HjVJ9458 pJwKzspQXwv3GTzqHETILNNHQ5blDY205eh.t.2bNsIrbvYWZ35tRVFeOIZ4 J5Wa.1rHJhvsn8UAbMpmqiDk4xvEYpjnUShcp7OZxbswYSd_BYg6.LxvaOw5 MjLXJTds7j1VpQwu7PG00KFsuR_Cgm96__vG8JVVN X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D6FD2AE.4010007@caucho.com> Date: Thu, 03 Mar 2011 09:41:02 -0800 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gabriel Montenegro References: <20110303164037.GC29234@shareable.org> <4D6FCD43.4000409@caucho.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 17:40:05 -0000 On 03/03/2011 09:26 AM, Gabriel Montenegro wrote: >> Should the following be removed from 4.5.3 "Pong", following that line of >> thinking? >> >> A Pong is issued only in response to the most recent Ping. >> >> >> Otherwise, the spec is making a decision against unidirectional keepalives. > [gab] Unidirectional keepalives were not originally discussed, so I would list them as stuff to be done afterwards. I would much rather we keep the basic Ping/Pong as in the spec, with the above which simplifies the implementation a lot (and provides one element of a rudimentary but effective DoS protection). That's not accurate, actually. Jamie Lokier raised similar issues about unidirectional keepalives well before we had any opcodes at all. One of the reason Willy suggested the ping/pong in the first place, as I recall, was to allow for unsolicited pongs. The sentence forbidding unsolicited pongs appeared without any discussion that I remember. >> There's also the option of pushing ping/pong to an extension if more >> time/experience is needed to get the definition right. > [gab] Given that it's been there for a long time, in the interest of having a simple spec soon, I'd rather we kept it as is, but postpone further refinements, timeouts etc for later. There's a difference. If the spec defines a request-response keepalive but forbids unsolicited keepalive, and if that's the wrong answer, it's doing more harm than good. That's not the same as restricting the spec to a simple definition. -- Scott > > From jamie@shareable.org Thu Mar 3 09:51:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0CA28C0E5 for ; Thu, 3 Mar 2011 09:51:04 -0800 (PST) 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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZ+-WSM7OgcB for ; Thu, 3 Mar 2011 09:51:03 -0800 (PST) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 8350428C0D6 for ; Thu, 3 Mar 2011 09:51:03 -0800 (PST) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1PvCh3-0000Bb-0t; Thu, 03 Mar 2011 17:52:05 +0000 Date: Thu, 3 Mar 2011 17:52:04 +0000 From: Jamie Lokier To: John Tamplin Message-ID: <20110303175204.GE29234@shareable.org> References: <20110303164037.GC29234@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" , Greg Wilkins Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 17:51:05 -0000 John Tamplin wrote: > My question is: do we really need to decide on > heartbeat/keep-alive/idle-timeouts etc now, or can we ship the > protocol without it (knowing that means applications will build their > own facility on top of it) and then later add it to the protocol when > we have actual usage data to look at to help drive consensus? > > My preference would be to keep the protocol simple now and add it > later, in the interest of getting something out soon. However, if the > consensus is that the base protocol must include this functionality, > then we have a lot more work to do including discussions like this. I agree with all of you that it should be left to the application for now (and maybe forever). However, Greg has correctly identified there is one area where timeout behaviour may already be occurring in WebSocket below the application, even if it is not specified anywhere. That is, when the WebSocket implementation times out a connection it thinks is dead, even if the application above it continues to just sit there waiting for data. HTTP servers universally do this, even though it is not specified, and I guess HTTP clients do it too. Generic WebSocket server implementations will probably tend to do it as well - just to avoid building up unbounded dead connections. Maybe that's just an implementation detail that applications (or application-specific protocols, when 3rd parties talk to each other) are expected to be aware of, and WebSocket implementations are expected to be configured appropriately for the application running over them; I'm not sure. There is no reason I can see why browser WebSockets should implement a timeout at all. If the Javascript application keeps the WebSocket object around without closing it, then let it stay open, so that application timeout policy is always followed. There is no need to protect applications that don't timeout themselves, unlike on the server where it is more useful, but it can remain something that WebSocket does not need to mandate. -- Jamie From Gabriel.Montenegro@microsoft.com Thu Mar 3 10:51:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A553A6A20 for ; Thu, 3 Mar 2011 10:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.504 X-Spam-Level: X-Spam-Status: No, score=-10.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vu9kuFQJzhMZ for ; Thu, 3 Mar 2011 10:51:08 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 7E0393A695F for ; Thu, 3 Mar 2011 10:51:08 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Mar 2011 10:52:17 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.270.2; Thu, 3 Mar 2011 10:52:16 -0800 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.139]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Thu, 3 Mar 2011 10:52:16 -0800 From: Gabriel Montenegro To: Scott Ferguson Thread-Topic: [hybi] Hello frames? Thread-Index: AQHL14412iWCpzy4ZUaGhFQV7JGbhJQXiymQgACrhQCAAE0vgIAAA14AgABt9ICAACx7gIAAZ7gAgAAT+ACAAAKrgIAACiAAgAAFsICAAAdbgIAAAh6AgAAEzoCAAAE4gIAAClCAgAKQzoCAAAM+gIAABy6A//97lCCAAIrhAP//jFEw Date: Thu, 3 Mar 2011 18:52:15 +0000 Message-ID: References: <20110303164037.GC29234@shareable.org> <4D6FCD43.4000409@caucho.com> <4D6FD2AE.4010007@caucho.com> In-Reply-To: <4D6FD2AE.4010007@caucho.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 18:51:13 -0000 > The sentence forbidding unsolicited pongs appeared without any > discussion that I remember. [gab] The intent was to simply say that *if* responding to a Ping, only the= last Ping need to be answered. I'm fine if folks want to see this clarifie= d by adding "*if/when responding to a Ping*, only the last Ping is responde= d to." I thought that was implicit, so was not quite sure why you claimed i= t prohibited unsolicited Pongs, even if it was not clear to me that was alr= eady allowed in the draft.=20 From ferg@caucho.com Thu Mar 3 11:31:00 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E953A69F4 for ; Thu, 3 Mar 2011 11:31:00 -0800 (PST) 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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIBIBs0sTTlS for ; Thu, 3 Mar 2011 11:30:59 -0800 (PST) Received: from nm26-vm0.bullet.mail.ac4.yahoo.com (nm26-vm0.bullet.mail.ac4.yahoo.com [98.139.52.242]) by core3.amsl.com (Postfix) with SMTP id 230F83A681B for ; Thu, 3 Mar 2011 11:30:59 -0800 (PST) Received: from [98.139.52.190] by nm26.bullet.mail.ac4.yahoo.com with NNFMP; 03 Mar 2011 19:32:04 -0000 Received: from [98.139.52.186] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 03 Mar 2011 19:32:04 -0000 Received: from [127.0.0.1] by omp1069.mail.ac4.yahoo.com with NNFMP; 03 Mar 2011 19:32:04 -0000 X-Yahoo-Newman-Id: 96684.56728.bm@omp1069.mail.ac4.yahoo.com Received: (qmail 97854 invoked from network); 3 Mar 2011 19:32:04 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 03 Mar 2011 11:32:03 -0800 PST X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: sjenwPgVM1nnzvLzgixhwG1HmgBY4_XC4k3BIE8o4QVme1i y8vtEnbZIi.H71Vd65l7YblMFSQ0jmH.x1a35n6P85Epb2wtTxiHZC8QqtQy A9WHE1r06FMfqtZXVUIYpEHbLbhHM6JZ.Vi0dlIwa.sQLZnJuZnBzWHJC_qC ODknMuONhtYkfDX0cFYBZlZGJcYY3An0pwQDgDiMzbQp6B_0eHQQonMf6_SW pMQ3RHdFcPbUEw201P7lgB6AZK4GCpErKgcdOqlAG4iGRq8Sy3A8DZ3t.BYy Mn7aTgB66MGFaKJyD0sozxmknUgSjLJcTekpXfssw6odIn8TGeFSTWCWYkoa kqbJ8ZIgj3s.Bl6r4o_pbGaJuyxCdgxaFOgQqzl8w7RcIYTKaB0E- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D6FECA7.709@caucho.com> Date: Thu, 03 Mar 2011 11:31:51 -0800 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gabriel Montenegro References: <20110303164037.GC29234@shareable.org> <4D6FCD43.4000409@caucho.com> <4D6FD2AE.4010007@caucho.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 19:31:00 -0000 On 03/03/2011 10:52 AM, Gabriel Montenegro wrote: >> The sentence forbidding unsolicited pongs appeared without any >> discussion that I remember. > [gab] The intent was to simply say that *if* responding to a Ping, only the last Ping need to be answered. I'm fine if folks want to see this clarified by adding "*if/when responding to a Ping*, only the last Ping is responded to." I thought that was implicit, so was not quite sure why you claimed it prohibited unsolicited Pongs, even if it was not clear to me that was already allowed in the draft. > Ah. In that case the wording would be clearer as something like "MAY send a pong for only the most recently received ping" because the current "is issued only" sounds like a MUST (and is ambiguous as to the context.) MUST would also be also because a client cannot rely on a server skipping pongs. (which is why the MAY/MUST convention is useful instead of wording like "is issued only") -- Scott > From andy.warmcat.com@googlemail.com Thu Mar 3 12:37:16 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954E93A6973 for ; Thu, 3 Mar 2011 12:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9i1Qwb0dxxW for ; Thu, 3 Mar 2011 12:37:15 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 4C6DE3A688F for ; Thu, 3 Mar 2011 12:37:15 -0800 (PST) Received: by wwb22 with SMTP id 22so1398864wwb.13 for ; Thu, 03 Mar 2011 12:38:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1LeYb6Vdxpk+BSj1HkUTLcdR8/1Mbry3AaPFAXGHYYw=; b=IGmyCTD/ODj/ari58R+I6um9J9kRQBjuGL6dlZun67S3LEEQlQdS5ZJOoNILc47nca RytYj7sD2+mJW+qbH88wD2L1wZbPlZRYYtq4kverQb8chp11o86KIm/LCe+dnSlbua+b JnWA7pUXzsRqM3yuZZxQs9PBA2hDoAGjYOM7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=WoRwmetxYs0ThMSLj3Gw2MaUEAmfdc+gj4MG0VxfizJrSZEDCVPSZaKlW7o0uGWXot tvtFuxPn/PfEuTcc3y7dZM0QJ+CyUQ/p48GENyHq2wB0ozT98BuD99JrV2bv9dt3l9PN E4xWej5Sx0FxbsxmYJQjNMbWo66wXFO6Z7UaY= Received: by 10.227.144.15 with SMTP id x15mr1341490wbu.188.1299184702801; Thu, 03 Mar 2011 12:38:22 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id o6sm1180232wbo.15.2011.03.03.12.38.20 (version=SSLv3 cipher=OTHER); Thu, 03 Mar 2011 12:38:21 -0800 (PST) Sender: Andy Green Message-ID: <4D6FFC3B.3090907@warmcat.com> Date: Thu, 03 Mar 2011 20:38:19 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jamie Lokier References: <20110303164037.GC29234@shareable.org> In-Reply-To: <20110303164037.GC29234@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" , Greg Wilkins Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 20:37:16 -0000 On 03/03/2011 04:40 PM, Somebody in the thread at some point said: > That information is crucial: You can't PING/PONG from the client > Javascript unless you know the client-side WebSocket timeout, and your > Sec-WebSocket-IdleTimeout header *does not give that value to the code > which needs it*. So real applications will have to receive it on the > server, and then send it in an application-specific control message > back to the client *anyway*. The correct place for it is in API that > the local Javascript can read, and maybe change, but nobody dares add > to the API. FWIW the selected protocol itself is another potential source of timeout knowledge, ie, both sides can understand because it is "superchat-1.0" protocol that was negotiated for the connection the idle timeout for the channel is 15s or whatever. -Andy From Martin.Thomson@andrew.com Thu Mar 3 13:33:54 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0A23A6835 for ; Thu, 3 Mar 2011 13:33:54 -0800 (PST) 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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlyXRz6+iqZW for ; Thu, 3 Mar 2011 13:33:53 -0800 (PST) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 22D053A6834 for ; Thu, 3 Mar 2011 13:33:52 -0800 (PST) X-AuditID: 0a0404e8-b7baaae00000654c-71-4d7009842ca5 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id B5.90.25932.489007D4; Thu, 3 Mar 2011 15:35:00 -0600 (CST) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 3 Mar 2011 15:34:59 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 4 Mar 2011 05:34:57 +0800 From: "Thomson, Martin" To: Jamie Lokier , Brodie Thiesfield Date: Fri, 4 Mar 2011 05:34:55 +0800 Thread-Topic: [hybi] Masked framing VS mask in frame Thread-Index: AcvZtgRykdMxkHIzROS+o5D+HDgUsAANLq6Q Message-ID: <8B0A9FCBB9832F43971E38010638454F04009F5170@SISPE7MB1.commscope.com> References: <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> <20110303151629.GA29234@shareable.org> In-Reply-To: <20110303151629.GA29234@shareable.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 21:33:54 -0000 On 2011-03-04 at 02:16:29, Jamie Lokier wrote: > Servers can _easily_ force clients to use a non-zero, varying mask -=20 > by looking at the mask, and if it's consistently the same for several=20 > frames in a row, reject the connection. Of course, if it's possible to get your attack in within those first few fr= ames, then nothing is gained. From gregw@intalio.com Thu Mar 3 13:34:31 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 125C13A6835 for ; Thu, 3 Mar 2011 13:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idLjw+B-BxTk for ; Thu, 3 Mar 2011 13:34:30 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id EC7EB3A6834 for ; Thu, 3 Mar 2011 13:34:29 -0800 (PST) Received: by vxg33 with SMTP id 33so1647017vxg.31 for ; Thu, 03 Mar 2011 13:35:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.98.132 with SMTP id ei4mr2593659vdb.190.1299188134161; Thu, 03 Mar 2011 13:35:34 -0800 (PST) Received: by 10.52.165.129 with HTTP; Thu, 3 Mar 2011 13:35:33 -0800 (PST) In-Reply-To: <20110303175204.GE29234@shareable.org> References: <20110303164037.GC29234@shareable.org> <20110303175204.GE29234@shareable.org> Date: Fri, 4 Mar 2011 08:35:33 +1100 Message-ID: From: Greg Wilkins To: Jamie Lokier Content-Type: multipart/alternative; boundary=20cf307ca3063bb582049d9acf18 Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 21:34:31 -0000 --20cf307ca3063bb582049d9acf18 Content-Type: text/plain; charset=ISO-8859-1 With regard to removing ping/pong, I've already found them very useful testing interoperability between different servers and clients - specifically jetty to libwebsockets. It would be a pity to lose this easy test vector. I think unsolicited pongs should also be supported. On 4 March 2011 04:52, Jamie Lokier wrote: > However, Greg has correctly identified there is one area where timeout > behaviour may already be occurring in WebSocket below the application, > even if it is not specified anywhere. > Exactly. Either the infrastructure does not attempt to timeout the connection OR it must divulge it's timeouts. Either is workable. I think the only thing that is not workable is the application being in control of keep alives, but having zero knowledge of what timeouts it has to meet. That will just result in frequent empty messages or ping/pongs. Note however, that because of intermediaries that will also be timing out connections, I think that keep alives will be somewhat of a black art for the the foreseeable future. Even if the client has no timeout (good idea) and the server knows it's own timeout, there will still be unexpected closes from NAT routers and the like. It is likely that keep alive packets will be needed and their frequency will need to be dynamically adjusted for the path - perhaps with a cache of known frequencies for paths. I don't expect many applications will go to such lengths, so websockets usage may just result in unreliable applications or overly frequent keep alives. Punting the hard problems to the application does not make them simpler. cheers --20cf307ca3063bb582049d9acf18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
With regard to removing ping/pong,=A0 I've already found them very = useful testing interoperability between different servers and clients - spe= cifically jetty to libwebsockets.=A0 It would be a pity to lose this easy t= est vector.

I think unsolicited pongs should also be supported.

On 4 March 2011 04:52, Jamie Lokier <= jamie@shareable.org> w= rote:
However, Greg has correctly identified there is one area where timeout
behaviour may already be occurring in WebSocket below the application,
even if it is not specified anywhere.

Exactly. =A0= Either the infrastructure does not attempt to timeout the connection OR it= must divulge it's timeouts.=A0 Either is workable. =A0 I think the onl= y thing that is not workable is the application being in control of keep al= ives, but having zero knowledge of what timeouts it has to meet.=A0 That wi= ll just result in frequent empty messages or ping/pongs.

Note however, that because of intermediaries that will also be timing o= ut connections, I think that keep alives will be somewhat of a black art fo= r the the foreseeable future.=A0 Even if the client has no timeout (good id= ea) and the server knows it's own timeout,=A0 there will still be unexp= ected closes from NAT routers and the like.=A0 It is likely that keep alive= packets will be needed and their frequency will need to be dynamically adj= usted for the path - perhaps with a cache of known frequencies for paths. = =A0 =A0 =A0=A0 I don't expect many applications will go to such lengths= , so websockets usage may just result in unreliable applications or overly = frequent keep alives. =A0 =A0=A0 Punting the hard problems to the applicati= on does not make them simpler.


cheers
=A0



=A0
--20cf307ca3063bb582049d9acf18-- From jat@google.com Thu Mar 3 13:51:47 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC01E3A68CE for ; Thu, 3 Mar 2011 13:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.933 X-Spam-Level: X-Spam-Status: No, score=-105.933 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox-Z8KOR5mJL for ; Thu, 3 Mar 2011 13:51:47 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DCA4A3A68B0 for ; Thu, 3 Mar 2011 13:51:46 -0800 (PST) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p23Lqrdl020192 for ; Thu, 3 Mar 2011 13:52:54 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299189174; bh=0jd7CXHZneuO/KktQZOK/sMHoz0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=mi0tDz0ErhqFoX5TeTpewS9Vf0tr/LagIbEMX8n4B8aZZ6OkpkQohRngHEVF6YGEG WFg8GoNcKK6AAv8OUVSng== Received: from ywg8 (ywg8.prod.google.com [10.192.7.8]) by hpaq6.eem.corp.google.com with ESMTP id p23LpNb3015267 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 3 Mar 2011 13:52:52 -0800 Received: by ywg8 with SMTP id 8so542856ywg.6 for ; Thu, 03 Mar 2011 13:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=s27b7Kq5opq8qSJtF/rykGi/kbBh1mpp73g5jb1GLs4=; b=Mcv1bqQKHcNGsGUgTQYmS59khnYfXenGoDlCEPRvknloKXTuJ2kcXGJxJc01Sf58jC W8L+PaE3txT7XNk/UN8g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Uq3ICv/fwAdI2Wkz/o8vPWIi8iCy3dUJ+yGetXGDI5Yt5Lio7Njk+KXKTridb50/Yp ciUTttstUnA6Q1EPqh4g== Received: by 10.151.14.12 with SMTP id r12mr2427855ybi.295.1299189172122; Thu, 03 Mar 2011 13:52:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Thu, 3 Mar 2011 13:52:32 -0800 (PST) In-Reply-To: References: <20110303164037.GC29234@shareable.org> <20110303175204.GE29234@shareable.org> From: John Tamplin Date: Thu, 3 Mar 2011 16:52:32 -0500 Message-ID: To: Greg Wilkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 21:51:47 -0000 On Thu, Mar 3, 2011 at 4:35 PM, Greg Wilkins wrote: > =C2=A0=C2=A0 Punting the hard problems to the application does not make t= hem simpler. No, but it does prevent us baking in a solution that doesn't actually solve the problem at hand because we have no experience with how WebSockets will actually be deployed. --=20 John A. Tamplin Software Engineer (GWT), Google From jamie@shareable.org Thu Mar 3 14:55:25 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72DD53A68CE for ; Thu, 3 Mar 2011 14:55:25 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U6qi6851Zie for ; Thu, 3 Mar 2011 14:55:24 -0800 (PST) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 9DF723A6889 for ; Thu, 3 Mar 2011 14:55:24 -0800 (PST) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1PvHRX-0001fv-G0; Thu, 03 Mar 2011 22:56:23 +0000 Date: Thu, 3 Mar 2011 22:56:23 +0000 From: Jamie Lokier To: "Thomson, Martin" Message-ID: <20110303225623.GF29234@shareable.org> References: <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> <20110303151629.GA29234@shareable.org> <8B0A9FCBB9832F43971E38010638454F04009F5170@SISPE7MB1.commscope.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B0A9FCBB9832F43971E38010638454F04009F5170@SISPE7MB1.commscope.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Hybi , Brodie Thiesfield , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 22:55:25 -0000 Thomson, Martin wrote: > On 2011-03-04 at 02:16:29, Jamie Lokier wrote: > > Servers can _easily_ force clients to use a non-zero, varying mask - > > by looking at the mask, and if it's consistently the same for several > > frames in a row, reject the connection. > > Of course, if it's possible to get your attack in within those first > few frames, then nothing is gained. Quite the opposite. What would be achieved (I won't call it a "gain" because I don't think it's a good idea) by proliferation of servers configured that way would be to prevent the widespread use of zero-masking legitimate clients, thereby rendering them unavailable as a hijackable attack vector (in the way that browsers are hijacked by scripts). So even if an attack is possible in the first few frames, it won't be possible to hijack clients to do it - which is the same as masking is designed to ensure. So the same motivation is there for paranoid server writers to refuse zero-masking connections, even if the spec doesn't say to do that, as there is to have masking in the first place. -- Jamie From Martin.Thomson@andrew.com Thu Mar 3 15:12:03 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C1993A6889 for ; Thu, 3 Mar 2011 15:12:03 -0800 (PST) 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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8l8yfWo46b2n for ; Thu, 3 Mar 2011 15:12:02 -0800 (PST) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 4C5823A687C for ; Thu, 3 Mar 2011 15:12:02 -0800 (PST) X-AuditID: 0a0404e9-b7c06ae000002334-40-4d702086aa9f Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 5D.3D.09012.680207D4; Thu, 3 Mar 2011 17:13:10 -0600 (CST) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 3 Mar 2011 17:13:09 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 4 Mar 2011 07:13:05 +0800 From: "Thomson, Martin" To: Jamie Lokier Date: Fri, 4 Mar 2011 07:13:05 +0800 Thread-Topic: [hybi] Masked framing VS mask in frame Thread-Index: AcvZ9jxBmsPltmvjRV6tVupXqEn2NwAAZZZQ Message-ID: <8B0A9FCBB9832F43971E38010638454F04009F5186@SISPE7MB1.commscope.com> References: <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> <20110303151629.GA29234@shareable.org> <8B0A9FCBB9832F43971E38010638454F04009F5170@SISPE7MB1.commscope.com> <20110303225623.GF29234@shareable.org> In-Reply-To: <20110303225623.GF29234@shareable.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Hybi , Brodie Thiesfield , Greg Wilkins Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 23:12:03 -0000 On 2011-03-04 at 09:56:23, Jamie Lokier wrote: > Thomson, Martin wrote: > > On 2011-03-04 at 02:16:29, Jamie Lokier wrote: > > > Servers can _easily_ force clients to use a non-zero, varying mask > - > > > by looking at the mask, and if it's consistently the same for=20 > > > several frames in a row, reject the connection. > > > > Of course, if it's possible to get your attack in within those first=20 > > few frames, then nothing is gained. >=20 > Quite the opposite. What would be achieved (I won't call it a "gain" > because I don't think it's a good idea) by proliferation of servers=20 > configured that way would be to prevent the widespread use of zero-=20 > masking legitimate clients, thereby rendering them unavailable as a=20 > hijackable attack vector (in the way that browsers are hijacked by=20 > scripts). >=20 > So even if an attack is possible in the first few frames, it won't be=20 > possible to hijack clients to do it - which is the same as masking is=20 > designed to ensure. So the same motivation is there for paranoid=20 > server writers to refuse zero-masking connections, even if the spec=20 > doesn't say to do that, as there is to have masking in the first place. Unfortunately, it doesn't prevent a lazy implementer from using a predictab= le sequence and leaving the door open in a less obvious fashion. All the b= ad guy needs is a reasonable probability of being able to predict the mask.= Zero mask is the degenerate case. There are lots of ways to set a mask t= hat isn't good enough. Detecting insufficient randomness is harder and tak= es a lot more frames. But that's only theory. In practice, I think that your suggestion might wo= rk for your stated goal if deployed by enough server implementations. It's= probably not a bad "Security Considerations" point. From gregw@intalio.com Thu Mar 3 17:09:01 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43E433A684A for ; Thu, 3 Mar 2011 17:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvcTWSEQeBcN for ; Thu, 3 Mar 2011 17:09:00 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 6695F3A683F for ; Thu, 3 Mar 2011 17:09:00 -0800 (PST) Received: by vxg33 with SMTP id 33so1818997vxg.31 for ; Thu, 03 Mar 2011 17:10:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.160.8 with SMTP id xg8mr2716282vdb.310.1299201008337; Thu, 03 Mar 2011 17:10:08 -0800 (PST) Received: by 10.52.165.129 with HTTP; Thu, 3 Mar 2011 17:10:08 -0800 (PST) In-Reply-To: <20110303225623.GF29234@shareable.org> References: <569915DD-DE46-4B3D-85FE-B14D18639936@gmail.com> <1298990267.2498.668.camel@ds9.ducksong.com> <20110303151629.GA29234@shareable.org> <8B0A9FCBB9832F43971E38010638454F04009F5170@SISPE7MB1.commscope.com> <20110303225623.GF29234@shareable.org> Date: Fri, 4 Mar 2011 12:10:08 +1100 Message-ID: From: Greg Wilkins To: Jamie Lokier Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi , Brodie Thiesfield , "Thomson, Martin" Subject: Re: [hybi] Masked framing VS mask in frame X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 01:09:01 -0000 Jamie, the same argument applies to why we should allow no masking and remove the motivation to game the masking algorithm. By not allowing a legitimate non-browser client to turn off masking in a well defined standardised way, we will just encourage a proliferation of implementations that will use zero, weak or copied keys. Prohibition of a desire never works as a policy - it just creates an uncontrolled black market. cheers From trac@tools.ietf.org Fri Mar 4 00:16:30 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0F0B3A6859 for ; Fri, 4 Mar 2011 00:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg+1l5sNQnrQ for ; Fri, 4 Mar 2011 00:16:29 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 804AA28C0E7 for ; Fri, 4 Mar 2011 00:16:24 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvQCX-0000w6-KW; Fri, 04 Mar 2011 00:17:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "hybi issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: ifette@google.com, salvatore.loreto@ericsson.com X-Trac-Project: hybi Date: Fri, 04 Mar 2011 08:17:29 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/hybi/trac/ticket/38#comment:1 Message-ID: <077.f07d19d9b54363779932307a7d53018b@tools.ietf.org> References: <068.fa117a4cfa2e0f927dd8249d378ff501@tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <068.fa117a4cfa2e0f927dd8249d378ff501@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: ifette@google.com, salvatore.loreto@ericsson.com, hybi@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: hybi@ietf.org Subject: Re: [hybi] #38: Error handling X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 08:16:31 -0000 #38: Error handling Changes (by salvatore.loreto@…): * owner: => ifette@… -- -------------------------------------------+-------------------------------- Reporter: salvatore.loreto@… | Owner: ifette@… Type: defect | Status: new Priority: major | Milestone: Component: thewebsocketprotocol | Version: Severity: - | Keywords: -------------------------------------------+-------------------------------- Ticket URL: hybi The Hypertext-Bidirectional (HyBi) working group will seek standardization of one approach to maintain bidirectional communications between the HTTP client, server and intermediate entities, which will provide more efficiency compared to the current use of hanging requests. From Yutaka_Takeda@PlayStation.Sony.Com Fri Mar 4 02:23:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789813A6A04 for ; Fri, 4 Mar 2011 02:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.005 X-Spam-Level: X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfPzVYqWzNv4 for ; Fri, 4 Mar 2011 02:23:32 -0800 (PST) Received: from paris.playstation.sony.com (nat.playstation.sony.com [69.36.131.254]) by core3.amsl.com (Postfix) with ESMTP id B52183A6A01 for ; Fri, 4 Mar 2011 02:23:32 -0800 (PST) Received: from constantine.playstation.sony.com ([162.49.67.15]) by paris.playstation.sony.com (Lotus Domino Release 8.5.1FP5) with ESMTP id 2011030402243973-53017 ; Fri, 4 Mar 2011 02:24:39 -0800 In-Reply-To: To: Greg Wilkins MIME-Version: 1.0 X-KeepSent: 5FDC41C8:2F4FD435-88257849:0034E865; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Yutaka_Takeda@PlayStation.Sony.Com Date: Fri, 4 Mar 2011 02:28:09 -0800 X-MIMETrack: Serialize by Router on SCEA919ML04/SCEA(Release 8.5.1FP3|May 23, 2010) at 03/04/2011 02:24:39 AM, Serialize complete at 03/04/2011 02:24:39 AM, Itemize by SMTP Server on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/04/2011 02:24:39 AM, Serialize by Router on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/04/2011 02:24:42 AM, Serialize complete at 03/04/2011 02:24:42 AM Content-Type: multipart/alternative; boundary="=_alternative 0039831288257849_=" Cc: "hybi@ietf.org" , "Simo.Veikkolainen@nokia.com" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 10:23:34 -0000 This is a multipart message in MIME format. --=_alternative 0039831288257849_= Content-Type: text/plain; charset="US-ASCII" > Note however, that because of intermediaries that will also be > timing out connections, I think that keep alives will be somewhat of > a black art for the the foreseeable future. Even if the client has > no timeout (good idea) and the server knows it's own timeout, there > will still be unexpected closes from NAT routers and the like. Right. A while ago, I had to detail with deciding ping packet interval to keep TCP NAT binding alive, and ended up with sending keepalive packets every 60 seconds. The interval timeout was determined from my research with more than 50 routers, and minimum time I have seen was 5 minutes, and from another similar research done by Saikat@Cornel Univ. seemed to have indicated that TCP NAT binding kept alive for more than 4 minutes. http://saikat.guha.cc/stunt-results.php? IETF behave WG attempted to define NAT behavior against TCP including binding lifetime: http://tools.ietf.org/html/rfc5382 The document requires TCP idle connection timeout MUST NOT be less than 2 hours. However, this document came out not a long ago, so we cannot assume that all NATs in the wild follow this spec. As far as I know, when TCP NAT binding timeouts, the NAT does not send anything. (no FIN nor RST) Therefore, when client or server sends a packet after that, the packet will be dropped at the router as it no longer has route for the packet. If you are lucky, you may get ICMP error that could trigger closing connection, but as you know you cannot assume ICMP packet to arrive all the time. Client would likely end up with retransmitting the packet for a while (usually 10 - 30 minutes - see tcp(7)) then finally the endpoints give up the connection. To make application code simpler, sending ping/pong every 1 to 3 minutes for inactive websocket sounds like a good idea to me. Timeout for pong to come back would also help detecting such broken pipe earlier. - Yutaka hybi-bounces@ietf.org wrote on 03/03/2011 01:35:33 PM: > > With regard to removing ping/pong, I've already found them very > useful testing interoperability between different servers and > clients - specifically jetty to libwebsockets. It would be a pity > to lose this easy test vector. > > I think unsolicited pongs should also be supported. > On 4 March 2011 04:52, Jamie Lokier wrote: > However, Greg has correctly identified there is one area where timeout > behaviour may already be occurring in WebSocket below the application, > even if it is not specified anywhere. > > Exactly. Either the infrastructure does not attempt to timeout the > connection OR it must divulge it's timeouts. Either is workable. > I think the only thing that is not workable is the application being > in control of keep alives, but having zero knowledge of what > timeouts it has to meet. That will just result in frequent empty > messages or ping/pongs. > > Note however, that because of intermediaries that will also be > timing out connections, I think that keep alives will be somewhat of > a black art for the the foreseeable future. Even if the client has > no timeout (good idea) and the server knows it's own timeout, there > will still be unexpected closes from NAT routers and the like. It > is likely that keep alive packets will be needed and their frequency > will need to be dynamically adjusted for the path - perhaps with a > cache of known frequencies for paths. I don't expect many > applications will go to such lengths, so websockets usage may just > result in unreliable applications or overly frequent keep alives. > Punting the hard problems to the application does not make them simpler. > > > cheers > > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --=_alternative 0039831288257849_= Content-Type: text/html; charset="US-ASCII"
> Note however, that because of intermediaries that will also be
> timing out connections, I think that keep alives will be somewhat of
> a black art for the the foreseeable future.  Even if the client has
> no timeout (good idea) and the server knows it's own timeout,  there
> will still be unexpected closes from NAT routers and the like.

Right. A while ago, I had to detail with deciding ping packet interval to keep TCP NAT binding
alive, and ended up with sending keepalive packets every 60 seconds. The interval timeout
was determined from my research with more than 50 routers, and minimum time I have seen was
5 minutes, and from another similar research done by Saikat@Cornel Univ. seemed to have
indicated that TCP NAT binding kept alive for more than 4 minutes.
http://saikat.guha.cc/stunt-results.php?

IETF behave WG attempted to define NAT behavior against TCP including binding lifetime:
http://tools.ietf.org/html/rfc5382
The document requires TCP idle connection timeout MUST NOT be less than 2 hours.
However, this document came out not a long ago, so we cannot assume that all NATs
in the wild follow this spec.

As far as I know, when TCP NAT binding timeouts, the NAT does not send anything. (no FIN nor RST)
Therefore, when client or server sends a packet after that, the packet will be dropped
at the router as it no longer has route for the packet. If you are lucky, you may get ICMP
error that could trigger closing connection, but as you know you cannot assume ICMP
packet to arrive all the time. Client would likely end up with retransmitting the packet for a while
(usually 10 - 30 minutes - see tcp(7)) then finally the endpoints give up the connection.

To make application code simpler, sending ping/pong every 1 to 3 minutes for
inactive websocket sounds like a good idea to me. Timeout for pong to come back
would also help detecting such broken pipe earlier.


- Yutaka



hybi-bounces@ietf.org wrote on 03/03/2011 01:35:33 PM:

>
> With regard to removing ping/pong,  I've already found them very
> useful testing interoperability between different servers and
> clients - specifically jetty to libwebsockets.  It would be a pity
> to lose this easy test vector.
>
> I think unsolicited pongs should also be supported.
> On 4 March 2011 04:52, Jamie Lokier <jamie@shareable.org> wrote:
> However, Greg has correctly identified there is one area where timeout
> behaviour may already be occurring in WebSocket below the application,
> even if it is not specified anywhere.
>
> Exactly.   Either the infrastructure does not attempt to timeout the
> connection OR it must divulge it's timeouts.  Either is workable.  
> I think the only thing that is not workable is the application being
> in control of keep alives, but having zero knowledge of what
> timeouts it has to meet.  That will just result in frequent empty
> messages or ping/pongs.
>
> Note however, that because of intermediaries that will also be
> timing out connections, I think that keep alives will be somewhat of
> a black art for the the foreseeable future.  Even if the client has
> no timeout (good idea) and the server knows it's own timeout,  there
> will still be unexpected closes from NAT routers and the like.  It
> is likely that keep alive packets will be needed and their frequency
> will need to be dynamically adjusted for the path - perhaps with a
> cache of known frequencies for paths.        I don't expect many
> applications will go to such lengths, so websockets usage may just
> result in unreliable applications or overly frequent keep alives.  
>    Punting the hard problems to the application does not make them simpler.
>
>
> cheers
>  
>
>
>
>  _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
 --=_alternative 0039831288257849_=-- From jamie@shareable.org Fri Mar 4 03:24:41 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D18AA3A6A15 for ; Fri, 4 Mar 2011 03:24:41 -0800 (PST) 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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKWBhkkYZSY2 for ; Fri, 4 Mar 2011 03:24:40 -0800 (PST) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 6DDD83A6A08 for ; Fri, 4 Mar 2011 03:24:40 -0800 (PST) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1PvT8g-0007dR-1s; Fri, 04 Mar 2011 11:25:42 +0000 Date: Fri, 4 Mar 2011 11:25:42 +0000 From: Jamie Lokier To: Yutaka_Takeda@PlayStation.Sony.Com Message-ID: <20110304112541.GG29234@shareable.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "hybi@ietf.org" , "Simo.Veikkolainen@nokia.com" , "Gabriel.Montenegro@microsoft.com" , Greg Wilkins Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 11:24:41 -0000 Yutaka_Takeda@PlayStation.Sony.Com wrote: > > Note however, that because of intermediaries that will also be > > timing out connections, I think that keep alives will be somewhat of > > a black art for the the foreseeable future. Even if the client has > > no timeout (good idea) and the server knows it's own timeout, there > > will still be unexpected closes from NAT routers and the like. > Right. A while ago, I had to detail with deciding ping packet interval > to keep TCP NAT binding > alive, and ended up with sending keepalive packets every 60 seconds. > The interval timeout > was determined from my research with more than 50 routers, and minimum > time I have seen was > 5 minutes, and from another similar research done by Saikat@Cornel > Univ. seemed to have > indicated that TCP NAT binding kept alive for more than 4 minutes. I have often used 3G mobile routes that timed out in less than 1 minute consistently, and sometimes in about 30 seconds. So for those I sent keepalive every 15 seconds - 3O seconds was unreliable. That was last checked about 3 years ago. > [1]http://saikat.guha.cc/stunt-results.php? > IETF behave WG attempted to define NAT behavior against TCP including > binding lifetime: > [2]http://tools.ietf.org/html/rfc5382 > The document requires TCP idle connection timeout MUST NOT be less > than 2 hours. > However, this document came out not a long ago, so we cannot assume > that all NATs > in the wild follow this spec. That is absurdly unrealistic for routers with limited memory when a large number of connections are made through them and those connections don't terminate cleanly, thus keeping NAT state open. When just one person is using certain P2P networks at home, I have seen 30 or more TCP SYNs _per second_ going out - over a 2Mbit ADSL. It's not immediately clear what kind of demand that places on NAT table size with a timeout of 2 hours, not least because it depends how many connections become established then get stuck, but I suspect it's more than current home routers allow for. > As far as I know, when TCP NAT binding timeouts, the NAT does not send > anything. (no FIN nor RST) Yes, that is my experience. It just drops the NAT state, sometimes to make room for another one. > Therefore, when client or server sends a packet after that, the packet > will be dropped > at the router as it no longer has route for the packet. If you are > lucky, you may get ICMP > error that could trigger closing connection, but as you know you > cannot assume ICMP > packet to arrive all the time. Client would likely end up with > retransmitting the packet for a while > (usually 10 - 30 minutes - see tcp(7)) then finally the endpoints give > up the connection. Yes, that is my experience. However even worse, if the client doesn't send anything, it's just _assumes_ it receives notification messages from the server when whatever it's subscribed to changes, then the client _never_ times out at the TCP level. That is why client applications have to timeout. The same is true on the server, to avoid accumulating an infinite number of dead sockets, and if it needs to know when subscribers have left. > To make application code simpler, sending ping/pong every 1 to 3 > minutes for inactive websocket sounds like a good idea to > me. Timeout for pong to come back would also help detecting such > broken pipe earlier. Who sends the ping - the client or the server? What if the connection is active in one direction and idle in the other direction? Does that count as idle or not? Independent keepalives and timeouts are more efficient. Ping/pong means you have to send packets more often for the same level of robustness. And it's useless if your application needs to detect broken connection more quickly, to start another connection, or connect to a backup site, or notify the user that the link is down. An online board game, or live Twitter display for example, or live stock price display, needs to detect broken connection more quickly than 1 to 3 minutes, so it can reconnect or notify the user of a problem. For that you need to send keepalives quite often. Then the latency-doubling effect of the ping/pong pattern becomes more significant. -- Jamie From mcmanus@ducksong.com Fri Mar 4 06:53:44 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C8A3A6864 for ; Fri, 4 Mar 2011 06:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1Y4eKjvGAcE for ; Fri, 4 Mar 2011 06:53:43 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id C8CB83A67F4 for ; Fri, 4 Mar 2011 06:53:43 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id 7E18B102A7; Fri, 4 Mar 2011 09:54:52 -0500 (EST) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 2BE9E10159 for ; Fri, 4 Mar 2011 09:54:48 -0500 (EST) From: "Pat McManus @Mozilla" To: hybi Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Mar 2011 09:54:19 -0500 Message-ID: <1299250460.2498.2058.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Subject: [hybi] any servers with deflate-stream for test? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 14:53:44 -0000 Hi - I'm in the process of updating firefox to ietf-06.. libwebsockets has been very useful to test against (thanks Andy!), but it doesn't appear to have support for deflate-stream. Has any server implemented that yet? Thanks, -Pat -- http://www.getfirefox.com/ From andy.warmcat.com@googlemail.com Fri Mar 4 07:37:49 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1F13A6906 for ; Fri, 4 Mar 2011 07:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8UCHVQTcvqL for ; Fri, 4 Mar 2011 07:37:47 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 748803A6893 for ; Fri, 4 Mar 2011 07:37:47 -0800 (PST) Received: by wwb22 with SMTP id 22so2108836wwb.13 for ; Fri, 04 Mar 2011 07:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9oKv1GhGmzE938l49iJB0HCtIvognq+/Til59GFX/aM=; b=uqSmito706W3A76xUmf1Qs1BurhHH7q24i8Ft7BsB1qAZhc3RHbLbHIjgslJggK2q2 xn50NiwYZeMZNUyYvpKn2FWh4SR5wlJcTN2AJf8Jzlf60mC7/y778I0E0i0CwBQSHLdD HShtdg6rkPehFwlD60H8ZUETrB2g0O7XG27iM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qdQjwOCMXktGQRLdPCHt0zFMFxiMLetrAS7bMAowDi2nZ1ch232f0tXf7vT+jDXsqr u1q9dxwYIy/ji+4jNfLFHOP2XIKXdu0i2fiVco7sLJ0LnKj8/4mo2+q74ksyU96rgyvu APeLZ88dZCgpR+G8VVeq8Dq633cGR1w8sfZwA= Received: by 10.227.171.207 with SMTP id i15mr679053wbz.121.1299253136066; Fri, 04 Mar 2011 07:38:56 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id y29sm1881242wbd.4.2011.03.04.07.38.54 (version=SSLv3 cipher=OTHER); Fri, 04 Mar 2011 07:38:55 -0800 (PST) Sender: Andy Green Message-ID: <4D71078D.8080506@warmcat.com> Date: Fri, 04 Mar 2011 15:38:53 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Pat McManus @Mozilla" References: <1299250460.2498.2058.camel@ds9.ducksong.com> In-Reply-To: <1299250460.2498.2058.camel@ds9.ducksong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi Subject: Re: [hybi] any servers with deflate-stream for test? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 15:37:49 -0000 On 03/04/2011 02:54 PM, Somebody in the thread at some point said: Hi - > Hi - I'm in the process of updating firefox to ietf-06.. libwebsockets > has been very useful to test against (thanks Andy!), but it doesn't > appear to have support for deflate-stream. Hey that's great you are finding it useful. > Has any server implemented that yet? Actually since I made myself look dumb trying to "fix" extended data length management because I never studied it closely enough, I resolved to implement the compression extension stuff this weekend. If you have any tips to point me in the right direction about good compression library or whatever it'll only speed it up. -Andy From jat@google.com Fri Mar 4 07:53:38 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2193A6969 for ; Fri, 4 Mar 2011 07:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.81 X-Spam-Level: X-Spam-Status: No, score=-105.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4o5O8SeGWtaS for ; Fri, 4 Mar 2011 07:53:37 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 0786F3A6946 for ; Fri, 4 Mar 2011 07:53:36 -0800 (PST) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p24FsiVH009630 for ; Fri, 4 Mar 2011 07:54:44 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299254084; bh=7rN0ncThBThc9NOYLrJZ1DkTDCM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=hgJ4jSV54NkzUu4Hz2BWHHyiiv873mSBMTLe4OSrIukwKxh4dJ2LUidMJiDvJXdMx jl8XMGju/sgs+G04QyI7A== Received: from gyd10 (gyd10.prod.google.com [10.243.49.202]) by hpaq14.eem.corp.google.com with ESMTP id p24FsgjT001455 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 4 Mar 2011 07:54:43 -0800 Received: by gyd10 with SMTP id 10so963554gyd.12 for ; Fri, 04 Mar 2011 07:54:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oG53xLZJ9tc3nOTgL6dpG8MElXHVcdaqFBfk3WxQh3k=; b=LDMly+37w5imKX7EdW5sC5tbPxrOLqj812uj5ZogayPYsXcnpItZCvyWFCKpgnSvkT 4HQXQQVZHZ0624T+Md6g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Pr1eMOzNRFlEJLG76dgQ0S+2Vtcv2lhZjR3J4UoUsAtsF5UmBxMgzeNKSU6HbD0b0m oK/JdIsBH9tECNwckFSQ== Received: by 10.151.157.9 with SMTP id j9mr903416ybo.409.1299254082124; Fri, 04 Mar 2011 07:54:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Fri, 4 Mar 2011 07:54:22 -0800 (PST) In-Reply-To: <4D71078D.8080506@warmcat.com> References: <1299250460.2498.2058.camel@ds9.ducksong.com> <4D71078D.8080506@warmcat.com> From: John Tamplin Date: Fri, 4 Mar 2011 10:54:22 -0500 Message-ID: To: Andy Green Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: hybi Subject: Re: [hybi] any servers with deflate-stream for test? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 15:53:38 -0000 On Fri, Mar 4, 2011 at 10:38 AM, Andy Green wrote: > If you have any tips to point me in the right direction about good > compression library or whatever it'll only speed it up. >From C, using zlib directly is straightforward. -- John A. Tamplin Software Engineer (GWT), Google From andy.warmcat.com@googlemail.com Fri Mar 4 07:55:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80EF23A6832 for ; Fri, 4 Mar 2011 07:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRrogF8O1NoR for ; Fri, 4 Mar 2011 07:55:57 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 493643A6802 for ; Fri, 4 Mar 2011 07:55:57 -0800 (PST) Received: by wyb42 with SMTP id 42so2403115wyb.31 for ; Fri, 04 Mar 2011 07:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=A7fbP91N7U8MgUALufgr8CBEkQNLURh+JRi9G8cInqc=; b=tyquJ0e/FHtsLCtAlx1bFLLhU5unwfIBXqBAHeH05B0XB1Aj1kHbw908j/cZDtzM6n t9DfXUb1uKGdqc3EfAS6t+yuXjJpdHff2/JZS49XeEAd7yiyFqYkzhKwdpkVYlC31oZo 2omhSmn8zMxaP3uFUZYS+2OqWuUi1GM0OCIbA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=SRlvjBk2jyRch0uDDEiwxAnmcWk7iyKo6Ea03mtrn9YiXXmKV8ZvbdoeVptttB/Dln PFWBDlDtxlGt6XH+Jh7Xkiop5aHiWY+g1OgqWsUkVGfNT17qoACFbEqI2Q9ID6dSM4uc MGhjc5sfqxXJvgbcPOTSMVPQCQGzHXQZVhCi8= Received: by 10.227.140.11 with SMTP id g11mr719741wbu.57.1299254225717; Fri, 04 Mar 2011 07:57:05 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id w25sm1890533wbd.17.2011.03.04.07.57.04 (version=SSLv3 cipher=OTHER); Fri, 04 Mar 2011 07:57:04 -0800 (PST) Sender: Andy Green Message-ID: <4D710BCF.3020908@warmcat.com> Date: Fri, 04 Mar 2011 15:57:03 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Tamplin References: <1299250460.2498.2058.camel@ds9.ducksong.com> <4D71078D.8080506@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi Subject: Re: [hybi] any servers with deflate-stream for test? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 15:55:58 -0000 On 03/04/2011 03:54 PM, Somebody in the thread at some point said: > On Fri, Mar 4, 2011 at 10:38 AM, Andy Green wrote: >> If you have any tips to point me in the right direction about good >> compression library or whatever it'll only speed it up. > > From C, using zlib directly is straightforward. Thanks; John pointed out the same, I'll take that route. -Andy From Yutaka_Takeda@PlayStation.Sony.Com Fri Mar 4 23:53:12 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85EF3A691A for ; Fri, 4 Mar 2011 23:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt+O44Us5ZJp for ; Fri, 4 Mar 2011 23:53:11 -0800 (PST) Received: from paris.playstation.sony.com (nat.playstation.sony.com [69.36.131.254]) by core3.amsl.com (Postfix) with ESMTP id 24FF33A6944 for ; Fri, 4 Mar 2011 23:53:10 -0800 (PST) Received: from constantine.playstation.sony.com ([162.49.67.15]) by paris.playstation.sony.com (Lotus Domino Release 8.5.1FP5) with ESMTP id 2011030423541988-88652 ; Fri, 4 Mar 2011 23:54:19 -0800 In-Reply-To: <20110304112541.GG29234@shareable.org> To: Jamie Lokier MIME-Version: 1.0 X-KeepSent: 8BBA4B5A:DD2E3CAB-8825784A:0026E55A; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Yutaka_Takeda@PlayStation.Sony.Com Date: Fri, 4 Mar 2011 23:54:17 -0800 X-MIMETrack: Serialize by Router on SCEA919ML04/SCEA(Release 8.5.1FP3|May 23, 2010) at 03/04/2011 11:54:19 PM, Serialize complete at 03/04/2011 11:54:19 PM, Itemize by SMTP Server on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/04/2011 11:54:19 PM, Serialize by Router on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/04/2011 11:54:21 PM, Serialize complete at 03/04/2011 11:54:21 PM Content-Type: multipart/alternative; boundary="=_alternative 002B6D0A8825784A_=" Cc: "hybi@ietf.org" , "Simo.Veikkolainen@nokia.com" , "Gabriel.Montenegro@microsoft.com" , Greg Wilkins Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 07:53:13 -0000 This is a multipart message in MIME format. --=_alternative 002B6D0A8825784A_= Content-Type: text/plain; charset="US-ASCII" hybi-bounces@ietf.org wrote on 03/04/2011 03:25:42 AM: > Yutaka_Takeda@PlayStation.Sony.Com wrote: > > > Note however, that because of intermediaries that will also be > > > timing out connections, I think that keep alives will be somewhat of > > > a black art for the the foreseeable future. Even if the client has > > > no timeout (good idea) and the server knows it's own timeout, there > > > will still be unexpected closes from NAT routers and the like. > > Right. A while ago, I had to detail with deciding ping packet interval > > to keep TCP NAT binding > > alive, and ended up with sending keepalive packets every 60 seconds. > > The interval timeout > > was determined from my research with more than 50 routers, and minimum > > time I have seen was > > 5 minutes, and from another similar research done by Saikat@Cornel > > Univ. seemed to have > > indicated that TCP NAT binding kept alive for more than 4 minutes. > > I have often used 3G mobile routes that timed out in less than 1 > minute consistently, and sometimes in about 30 seconds. > So for those I sent keepalive every 15 seconds - 3O seconds was > unreliable. That was last checked about 3 years ago. Ouch.. I looked for any known spec for idle connection timeout with 3G but I could not come across any... Do you know any? > > > [1]http://saikat.guha.cc/stunt-results.php? > > IETF behave WG attempted to define NAT behavior against TCP including > > binding lifetime: > > [2]http://tools.ietf.org/html/rfc5382 > > The document requires TCP idle connection timeout MUST NOT be less > > than 2 hours. > > However, this document came out not a long ago, so we cannot assume > > that all NATs > > in the wild follow this spec. > > That is absurdly unrealistic for routers with limited memory when a > large number of connections are made through them and those > connections don't terminate cleanly, thus keeping NAT state open. Agree. The behave WG's scope includes carrier grade NAT, may not be practical for residential routers. The document also says "MAY" to drop existing bindings for new connections, it does not help our issue anyway.. > When just one person is using certain P2P networks at home, I have > seen 30 or more TCP SYNs _per second_ going out - over a 2Mbit ADSL. > It's not immediately clear what kind of demand that places on NAT > table size with a timeout of 2 hours, not least because it depends how > many connections become established then get stuck, but I suspect it's > more than current home routers allow for. > > > As far as I know, when TCP NAT binding timeouts, the NAT does not send > > anything. (no FIN nor RST) > > Yes, that is my experience. It just drops the NAT state, sometimes to > make room for another one. > > > Therefore, when client or server sends a packet after that, the packet > > will be dropped > > at the router as it no longer has route for the packet. If you are > > lucky, you may get ICMP > > error that could trigger closing connection, but as you know you > > cannot assume ICMP > > packet to arrive all the time. Client would likely end up with > > retransmitting the packet for a while > > (usually 10 - 30 minutes - see tcp(7)) then finally the endpoints give > > up the connection. > > Yes, that is my experience. > > However even worse, if the client doesn't send anything, it's just > _assumes_ it receives notification messages from the server when > whatever it's subscribed to changes, then the client _never_ times out > at the TCP level. > > That is why client applications have to timeout. Agreed. > > The same is true on the server, to avoid accumulating an infinite > number of dead sockets, and if it needs to know when subscribers have > left. > > > To make application code simpler, sending ping/pong every 1 to 3 > > minutes for inactive websocket sounds like a good idea to > > me. Timeout for pong to come back would also help detecting such > > broken pipe earlier. > > Who sends the ping - the client or the server? In SIP, specifically, RFC 5626("Client-Initialted Connections in SIP", Section 4.4), UAC(User Agent Client) sends ping, not from a server, but it allows the server to tell client "how long it can wait for ping before it concludes that connection is dead" with an optional header, 'Flow-Timer' header in its REGISTER method transaction. If the header is present, client adjust its ping/pong timers reflecting what server says with Flow-Timer header. The UAC waits for 'pong' after sending 'ping' up to 10 seconds before it gives up the connection, which is described in section 4.4.1. with some rationale. In the section, ping/pong interval time is defined as 120 seconds where battery power is not a concern, and 840 seconds where battery power is a concern. In it's rationale paragraph, it is assumed that TCP NAT timeout it as low as 15 minites, which differs from what I have seen in the past, and may not work for other reasons of connection loss. (e.g. 3G as you pointed out) Anyways, I just thought we may want to look into SIP's solution to this issue as what they are trying to achieve looks exactly the same as WebSocket's, and their method received consensus at least within SIP community. - Yutaka > > What if the connection is active in one direction and idle in the > other direction? Does that count as idle or not? > > Independent keepalives and timeouts are more efficient. > > Ping/pong means you have to send packets more often for the same > level of robustness. > > And it's useless if your application needs to detect broken connection > more quickly, to start another connection, or connect to a backup > site, or notify the user that the link is down. > > An online board game, or live Twitter display for example, or live > stock price display, needs to detect broken connection more quickly > than 1 to 3 minutes, so it can reconnect or notify the user of a problem. > > For that you need to send keepalives quite often. Then the > latency-doubling effect of the ping/pong pattern becomes more > significant. > > -- Jamie > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --=_alternative 002B6D0A8825784A_= Content-Type: text/html; charset="US-ASCII"
hybi-bounces@ietf.org wrote on 03/04/2011 03:25:42 AM:

> Yutaka_Takeda@PlayStation.Sony.Com wrote:
> >    > Note however, that because of intermediaries that will also be
> >    > timing out connections, I think that keep alives will be somewhat of
> >    > a black art for the the foreseeable future.  Even if the client has
> >    > no timeout (good idea) and the server knows it's own timeout,  there
> >    > will still be unexpected closes from NAT routers and the like.
> >    Right. A while ago, I had to detail with deciding ping packet interval
> >    to keep TCP NAT binding
> >    alive, and ended up with sending keepalive packets every 60 seconds.
> >    The interval timeout
> >    was determined from my research with more than 50 routers, and minimum
> >    time I have seen was
> >    5 minutes, and from another similar research done by Saikat@Cornel
> >    Univ. seemed to have
> >    indicated that TCP NAT binding kept alive for more than 4 minutes.
>
> I have often used 3G mobile routes that timed out in less than 1
> minute consistently, and sometimes in about 30 seconds.
> So for those I sent keepalive every 15 seconds - 3O seconds was
> unreliable.  That was last checked about 3 years ago.

Ouch.. I looked for any known spec for idle connection
timeout with 3G but I could not come across any... Do you
know any?


>
> >    [1]http://saikat.guha.cc/stunt-results.php?
> >    IETF behave WG attempted to define NAT behavior against TCP including
> >    binding lifetime:
> >    [2]http://tools.ietf.org/html/rfc5382
> >    The document requires TCP idle connection timeout MUST NOT be less
> >    than 2 hours.
> >    However, this document came out not a long ago, so we cannot assume
> >    that all NATs
> >    in the wild follow this spec.
>
> That is absurdly unrealistic for routers with limited memory when a
> large number of connections are made through them and those
> connections don't terminate cleanly, thus keeping NAT state open.

Agree. The behave WG's scope includes carrier grade NAT, may not be
practical for residential routers. The document also says "MAY" to
drop existing bindings for new connections, it does not help our
issue anyway..


> When just one person is using certain P2P networks at home, I have
> seen 30 or more TCP SYNs _per second_ going out - over a 2Mbit ADSL.
> It's not immediately clear what kind of demand that places on NAT
> table size with a timeout of 2 hours, not least because it depends how
> many connections become established then get stuck, but I suspect it's
> more than current home routers allow for.
>
> >    As far as I know, when TCP NAT binding timeouts, the NAT does not send
> >    anything. (no FIN nor RST)
>
> Yes, that is my experience.  It just drops the NAT state, sometimes to
> make room for another one.
>
> >    Therefore, when client or server sends a packet after that, the packet
> >    will be dropped
> >    at the router as it no longer has route for the packet. If you are
> >    lucky, you may get ICMP
> >    error that could trigger closing connection, but as you know you
> >    cannot assume ICMP
> >    packet to arrive all the time. Client would likely end up with
> >    retransmitting the packet for a while
> >    (usually 10 - 30 minutes - see tcp(7)) then finally the endpoints give
> >    up the connection.
>
> Yes, that is my experience.
>
> However even worse, if the client doesn't send anything, it's just
> _assumes_ it receives notification messages from the server when
> whatever it's subscribed to changes, then the client _never_ times out
> at the TCP level.
>
> That is why client applications have to timeout.

Agreed.

>
> The same is true on the server, to avoid accumulating an infinite
> number of dead sockets, and if it needs to know when subscribers have
> left.
>
> >    To make application code simpler, sending ping/pong every 1 to 3
> >    minutes for inactive websocket sounds like a good idea to
> >    me. Timeout for pong to come back would also help detecting such
> >    broken pipe earlier.
>
> Who sends the ping - the client or the server?

In SIP, specifically, RFC 5626("Client-Initialted Connections in SIP",
Section 4.4), UAC(User Agent Client) sends ping, not from a server,
but it allows the server to tell client "how long it can wait for ping
before it concludes that connection is dead" with an optional header,
'Flow-Timer' header in its REGISTER method transaction. If the header
is present, client adjust its ping/pong timers reflecting what server
says with Flow-Timer header.

The UAC waits for 'pong' after sending 'ping' up to 10 seconds before
it gives up the connection, which is described in section 4.4.1. with
some rationale.

In the section, ping/pong interval time is defined as 120 seconds
where battery power is not a concern, and 840 seconds where battery
power is a concern. In it's rationale paragraph, it is assumed that
TCP NAT timeout it as low as 15 minites, which differs from what I have
seen in the past, and may not work for other reasons of connection
loss. (e.g. 3G as you pointed out)

Anyways, I just thought we may want to look into SIP's solution to
this issue as what they are trying to achieve looks exactly the same
as WebSocket's, and their method received consensus at least within SIP
community.

- Yutaka

>
> What if the connection is active in one direction and idle in the
> other direction?  Does that count as idle or not?
>
> Independent keepalives and timeouts are more efficient.
>
> Ping/pong means you have to send packets more often for the same
> level of robustness.
>
> And it's useless if your application needs to detect broken connection
> more quickly, to start another connection, or connect to a backup
> site, or notify the user that the link is down.
>
> An online board game, or live Twitter display for example, or live
> stock price display, needs to detect broken connection more quickly
> than 1 to 3 minutes, so it can reconnect or notify the user of a problem.
>
> For that you need to send keepalives quite often.  Then the
> latency-doubling effect of the ping/pong pattern becomes more
> significant.
>
> -- Jamie
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
 --=_alternative 002B6D0A8825784A_=-- From gregw@intalio.com Sat Mar 5 13:01:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4F83A6AC0 for ; Sat, 5 Mar 2011 13:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATURWVmEhl1g for ; Sat, 5 Mar 2011 13:01:14 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 78D643A69E3 for ; Sat, 5 Mar 2011 13:01:14 -0800 (PST) Received: by vws6 with SMTP id 6so3326011vws.31 for ; Sat, 05 Mar 2011 13:02:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.92.34 with SMTP id cj2mr3091930vdb.183.1299358909216; Sat, 05 Mar 2011 13:01:49 -0800 (PST) Received: by 10.52.169.67 with HTTP; Sat, 5 Mar 2011 13:01:49 -0800 (PST) Date: Sun, 6 Mar 2011 08:01:49 +1100 Message-ID: From: Greg Wilkins To: Yutaka_Takeda@playstation.sony.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" , "Simo.Veikkolainen@nokia.com" , "Gabriel.Montenegro@microsoft.com" Subject: [hybi] Keep-Alive, was: Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 21:01:15 -0000 On 5 March 2011 18:54, wrote: > Anyways, I just thought we may want to look into SIP's solution to > this issue.... Well I think the first thing we need to decide is if we want to do something about this either now or in an early rev of the spec. The characteristic of this problem is that it is very hard to solve well (send keep alives at just the right frequency), very easy to solve badly (send keep alives very frequently or reopen after every close(which you might not detect)) and really easy to not solve at all (and hope the user is busy enough to keep the connection alive and not fussy enough to care if it locks up when idle). Given that bad or non solutions are easy, then if we leave this problem to the applications, then we can expect a large number bad and non solutions to be deployed. Worse still, once applications have been deployed with a bad solution, it will make it harder for future work on the protocol to fix the problem, because the applications will be out there pinging away at 15s intervals and will remain there until all the old browsers are replaced. I believe that it is the goal of websockets to provided long lived bidirectional connections. It strikes me as counterproductive if the standard provides no mechanism to ensure that the connection are either long lived or still connected. It is going to result in many many frustrated tic tack toe players who are waiting for hours for their opponent to move, when a NAT router has just timedout silently. If we don't want to complicate the base protocol, then we should have standard keep-alive extension that will use a combination of dynamic timeouts and connection retries to both keep a connection alive and to discover the best timeout to use for a given destination. regards From Yutaka_Takeda@PlayStation.Sony.Com Sat Mar 5 17:41:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8FB3A6AA1 for ; Sat, 5 Mar 2011 17:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.714 X-Spam-Level: X-Spam-Status: No, score=-5.714 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8RYnBXF8dHT for ; Sat, 5 Mar 2011 17:41:41 -0800 (PST) Received: from paris.playstation.sony.com (nat.playstation.sony.com [69.36.131.254]) by core3.amsl.com (Postfix) with ESMTP id 29C133A69BE for ; Sat, 5 Mar 2011 17:41:40 -0800 (PST) Received: from constantine.playstation.sony.com ([162.49.67.15]) by paris.playstation.sony.com (Lotus Domino Release 8.5.1FP5) with ESMTP id 2011030517425158-101546 ; Sat, 5 Mar 2011 17:42:51 -0800 In-Reply-To: To: Greg Wilkins MIME-Version: 1.0 X-KeepSent: 9BB20F1D:0D8791FE-8825784B:00034BFE; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Yutaka_Takeda@PlayStation.Sony.Com Date: Sat, 5 Mar 2011 17:42:44 -0800 X-MIMETrack: Serialize by Router on SCEA919ML04/SCEA(Release 8.5.1FP3|May 23, 2010) at 03/05/2011 05:42:51 PM, Serialize complete at 03/05/2011 05:42:51 PM, Itemize by SMTP Server on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/05/2011 05:42:51 PM, Serialize by Router on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/05/2011 05:42:52 PM, Serialize complete at 03/05/2011 05:42:52 PM Content-Type: multipart/alternative; boundary="=_alternative 000968DC8825784B_=" Cc: "hybi@ietf.org" , "Simo.Veikkolainen@nokia.com" , "Gabriel.Montenegro@microsoft.com" Subject: Re: [hybi] Keep-Alive, was: Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 01:41:42 -0000 This is a multipart message in MIME format. --=_alternative 000968DC8825784B_= Content-Type: text/plain; charset="US-ASCII" Greg Wilkins wrote on 03/05/2011 01:01:49 PM: > Well I think the first thing we need to decide is if we want to do > something about this either now or in an early rev of the spec. > > The characteristic of this problem is that it is very hard to solve > well (send keep alives at just the right frequency), very easy to > solve badly (send keep alives very frequently or reopen after every > close(which you might not detect)) and really easy to not solve at all > (and hope the user is busy enough to keep the connection alive and not > fussy enough to care if it locks up when idle). > > Given that bad or non solutions are easy, then if we leave this > problem to the applications, then we can expect a large number bad and > non solutions to be deployed. Worse still, once applications have > been deployed with a bad solution, it will make it harder for future > work on the protocol to fix the problem, because the applications will > be out there pinging away at 15s intervals and will remain there until > all the old browsers are replaced. Right. Very important point. > > I believe that it is the goal of websockets to provided long lived > bidirectional connections. It strikes me as counterproductive if the > standard provides no mechanism to ensure that the connection are > either long lived or still connected. It is going to result in many > many frustrated tic tack toe players who are waiting for hours for > their opponent to move, when a NAT router has just timedout silently. Indeed. > If we don't want to complicate the base protocol, then we should have > standard keep-alive extension that will use a combination of dynamic > timeouts and connection retries to both keep a connection alive and to > discover the best timeout to use for a given destination. I am OK with having keep-alive extension separate from the base protocol. But, as enabling long lived bidirectional connections is being one of the important goals of WebSocket, it is still a high priority issue especially when we can see possible bad user experience without addressing it. Having said that, we are probably not able to come up with "the best" ping intervals that stands forever since there would be many variable factors overtime that could invalidate our best assumption we can currently make. Therefore, we should define a framework that can let us later adjust keepalive timeouts, perhaps as BCP as we find something better in the future. How about introducing something like in the handshake: Sec-WebSocket-KeepAlive: interval=120, timeout=10 Client MAY add this in its request(handshake) if these values are important for the client, then the server SHOULD add the same header with final values which was determined considering what client requested for if any, as well as server side arbitrary factors such as current load. Then the client MUST follow the final values provided by the server, if the header is present in 101 response. We should also recommend default values in the base protocol that we think best for the time being (e.g. 120 sec/10 sec, as in SIP). - Yutaka --=_alternative 000968DC8825784B_= Content-Type: text/html; charset="US-ASCII"
Greg Wilkins <gregw@intalio.com> wrote on 03/05/2011 01:01:49 PM:
> Well I think the first thing we need to decide is if we want to do
> something about this either now or in an early rev of the spec.
>
> The characteristic of this problem is that it is very hard to solve
> well (send keep alives at just the right frequency), very easy to
> solve badly (send keep alives very frequently or reopen after every
> close(which you might not detect)) and really easy to not solve at all
> (and hope the user is busy enough to keep the connection alive and not
> fussy enough to care if it locks up when idle).
>
> Given that bad or non solutions are easy, then if we leave this
> problem to the applications, then we can expect a large number bad and
> non solutions to be deployed.    Worse still, once applications have
> been deployed with a bad solution, it will make it harder for future
> work on the protocol to fix the problem, because the applications will
> be out there pinging away at 15s intervals and will remain there until
> all the old browsers are replaced.

Right. Very important point.

>
> I believe that it is the goal of websockets to provided long lived
> bidirectional connections.   It strikes me as counterproductive if the
> standard provides no mechanism to ensure that the connection are
> either long lived or still connected.  It is going to result in many
> many frustrated tic tack toe players who are waiting for hours for
> their opponent to move, when  a NAT router has just timedout silently.
Indeed.

> If we don't want to complicate the base protocol, then we should have
> standard keep-alive extension that will use a combination of dynamic
> timeouts and connection retries to both keep a connection alive and to
> discover the best timeout to use for a given destination.
I am OK with having keep-alive extension separate from the base protocol.
But, as enabling long lived bidirectional connections is being one of
the important goals of WebSocket, it is still a high priority issue
especially when we can see possible bad user experience without
addressing it.

Having said that, we are probably not able to come up with "the best"
ping intervals that stands forever since there would be many variable
factors overtime that could invalidate our best assumption we can
currently make. Therefore, we should define a framework that can let
us later adjust keepalive timeouts, perhaps as BCP as we find something
better in the future.

How about introducing something like in the handshake:

   Sec-WebSocket-KeepAlive: interval=120, timeout=10

Client MAY add this in its request(handshake) if these values are
important for the client, then the server SHOULD add the same header
with final values which was determined considering what client
requested for if any, as well as server side arbitrary factors such as
current load. Then the client MUST follow the final values provided
by the server, if the header is present in 101 response.

We should also recommend default values in the base protocol that we
think best for the time being (e.g. 120 sec/10 sec, as in SIP).


- Yutaka

  --=_alternative 000968DC8825784B_=-- From trac@tools.ietf.org Sat Mar 5 17:49:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7FC63A6ACA for ; Sat, 5 Mar 2011 17:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1n4e4WkvJq6 for ; Sat, 5 Mar 2011 17:49:58 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3EC603A6AA1 for ; Sat, 5 Mar 2011 17:49:58 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pw37k-0002lo-3U; Sat, 05 Mar 2011 17:51:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "hybi issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: sm+ietf@elandsys.com X-Trac-Project: hybi Date: Sun, 06 Mar 2011 01:51:08 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/hybi/trac/ticket/44 Message-ID: <059.4db1775b8c4af98d4ef0bc6a8a3029cd@tools.ietf.org> X-Trac-Ticket-ID: 44 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: sm+ietf@elandsys.com, hybi@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: hybi@ietf.org Subject: [hybi] #44: Change Controller for the URI schemes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 01:49:59 -0000 #44: Change Controller for the URI schemes The Change Controller for the URI schemes is incorrect. -- ----------------------------------+----------------------------------------- Reporter: sm+ietf@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: thewebsocketprotocol | Version: Severity: - | Keywords: ----------------------------------+----------------------------------------- Ticket URL: hybi The Hypertext-Bidirectional (HyBi) working group will seek standardization of one approach to maintain bidirectional communications between the HTTP client, server and intermediate entities, which will provide more efficiency compared to the current use of hanging requests. From andy.warmcat.com@googlemail.com Sun Mar 6 01:30:11 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0833A67AE for ; Sun, 6 Mar 2011 01:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EsCC1y1QQaW for ; Sun, 6 Mar 2011 01:30:10 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 2A3363A6944 for ; Sun, 6 Mar 2011 01:30:09 -0800 (PST) Received: by wwb22 with SMTP id 22so3088934wwb.13 for ; Sun, 06 Mar 2011 01:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pUEbhFWxUdqpO/0kLP8v15OhWjUCd7yHOfUguIaC9ys=; b=QjOAhZDRdwuA2jvr4ruo7kc/p/B81ZgYV9W4HYeDQPUocftqkaRqtihBnplmMyuWwG DnVDl5qjsSBd6vuy06ui2cpOiY95ZJqXzZc0HWUBdmAK7Cr/hIOU84BnolwzVSvhmLMP zYh7Z3OhfsA4h/0pVN0Cb7j8GOYZ0xGFoJGEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=PI0uEt6dgXAz9NSOPbbAgeB8aySMQ1bUdgF0zechJbB8kB9qcKl2wEYopQSnarPGws EyGVHA5Vd4q/OVkja77uuHIBA4kYeVcyAUk2SiMvkhzF8VeJaDc+rrInqmYSuKDukFD1 k+K3Ij9zWVr48qLwiw7zEcK2w/2fkX034/BX4= Received: by 10.227.140.77 with SMTP id h13mr2246746wbu.217.1299403879694; Sun, 06 Mar 2011 01:31:19 -0800 (PST) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id o6sm1120914wbo.21.2011.03.06.01.31.17 (version=SSLv3 cipher=OTHER); Sun, 06 Mar 2011 01:31:18 -0800 (PST) Sender: Andy Green Message-ID: <4D735465.9060706@warmcat.com> Date: Sun, 06 Mar 2011 09:31:17 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yutaka_Takeda@PlayStation.Sony.Com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Gabriel.Montenegro@microsoft.com" , Greg Wilkins Subject: Re: [hybi] Keep-Alive, was: Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 09:30:11 -0000 On 03/06/2011 01:42 AM, Somebody in the thread at some point said: Hi - > Sec-WebSocket-KeepAlive: interval=120, timeout=10 > > Client MAY add this in its request(handshake) if these values are > important for the client, then the server SHOULD add the same header > with final values which was determined considering what client > requested for if any, as well as server side arbitrary factors such as > current load. Then the client MUST follow the final values provided > by the server, if the header is present in 101 response. > > We should also recommend default values in the base protocol that we > think best for the time being (e.g. 120 sec/10 sec, as in SIP). Right it'd be nice to do it in the header, because in addition to the client being able to propose, and the server being able to decide, it's possible for intermediaries to rewrite the client numbers downwards as they pass it through if in fact they have a shorter close-on-idle policy themselves. There's no point the server mandating an idle timeout that can never be reached because an intermediary will drop the connection before. So it can serve as a probe to find the smallest idle timeout period amongst websocket-aware guys anyway. Also the header is definitely always talking about things that apply to the whole connection, which is appropriate for connection idle timeout. How about this definition of what this "keep alive" or "idle timeout" means --> If either side saw any kind of websocket traffic come from their peer, they can reset their idle timeout on their side (because they know the channel is working). So if there is even slow periodic data coming from the peer you never have to send a PING. If you don't see any other traffic come from the peer for, say, 0.5 of the idle timeout period and each 0.1 additionally if needed, you should try to provoke incoming traffic by sending a PING. If still no incoming traffic is coming from the peer by the idle timeout period, they should close the connection from their side. At that time, it doesn't seem to make sense to try to use the controlled close stuff because we just identified the link won't carry any traffic, so just close the socket. -Andy From andy.warmcat.com@googlemail.com Sun Mar 6 05:57:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1AC3A67D2 for ; Sun, 6 Mar 2011 05:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRSKtv0WLklN for ; Sun, 6 Mar 2011 05:57:37 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 57CA13A67CF for ; Sun, 6 Mar 2011 05:57:37 -0800 (PST) Received: by wyb42 with SMTP id 42so3791886wyb.31 for ; Sun, 06 Mar 2011 05:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f7j/Q3aVY6d1IESBFoFK3d/KWBFsjJpBBgP44LuW1Gc=; b=B6P/yaXS/loGZeVm1wdvA9LCEIp4PcYh33WzYaqDJTFr1D/T6bdAmoQAksLSbqFVea IkrGTx5onFgVTjICV3SkzhIPc0iZ0VpWNGGxjzTEC6jbTat83AliQasDg15ezuDGr0HA 90JV1p3ACKN1VYkdC2KeSiZrxouWLIgGyEWew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=C+uoaamtkeuoqwvyJxjiGUURzh5x4rfEP+TXOmub7qzmK6Bjba7byYGQ6RLBwaAy9a Yw7nlBiKQbXw2cA1/iCHF8fI5m/SJijke2UMZO9dkPuPG4GcwGqLl41yOLoQXERJsQUB 34Bs5t3PqrnNqVBnUXF3/ZJ3uYE9Ast7/5KiM= Received: by 10.227.139.164 with SMTP id e36mr2494069wbu.94.1299419927934; Sun, 06 Mar 2011 05:58:47 -0800 (PST) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id bd8sm1284315wbb.1.2011.03.06.05.58.46 (version=SSLv3 cipher=OTHER); Sun, 06 Mar 2011 05:58:46 -0800 (PST) Sender: Andy Green Message-ID: <4D739315.10209@warmcat.com> Date: Sun, 06 Mar 2011 13:58:45 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Tamplin References: <1299250460.2498.2058.camel@ds9.ducksong.com> <4D71078D.8080506@warmcat.com> <4D710BCF.3020908@warmcat.com> In-Reply-To: <4D710BCF.3020908@warmcat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi Subject: Re: [hybi] any servers with deflate-stream for test? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 13:57:48 -0000 On 03/04/2011 03:57 PM, Somebody in the thread at some point said: > On 03/04/2011 03:54 PM, Somebody in the thread at some point said: >> On Fri, Mar 4, 2011 at 10:38 AM, Andy Green wrote: >>> If you have any tips to point me in the right direction about good >>> compression library or whatever it'll only speed it up. >> >> From C, using zlib directly is straightforward. > > Thanks; John pointed out the same, I'll take that route. Hi - This is added and working now, at least for me ^^ http://git.warmcat.com/cgi-bin/cgit/libwebsockets/ By default, all v4, v5 or v6 clients will offer deflate-stream now with the existing test apps and the server will by default always accept deflate-stream when the connecting client offers it. Here's some more information about the changes in the library, you don't need to know it to use the libwebsockets-test-server app with a client that offers deflate-stream though. You can now define a set of extensions that are available when you create the libwebsockets context. I guess most extensions will be common in the end and best done inside the library like deflate-stream, so I exported a list of internally supported extensions for clients and servers to use and added deflate-stream to it. (The test clients and servers are all updated to use that). The clients list all the extensions they know about on the client header line, and call an optional callback for each one into user code to make sure it's wanted to be announced (there is a -u --undeflated switch added to the test client that disables announcing deflate-stream using this method). Similarly, the server code calls a callback into user code for each extension to check which extensions the client announced it wants to accept. As it compiles the list it instantiates the accepted extensions and attaches them to a per-connection list. When the client gets the server handshake response, it instantiates that extension support and adds it to a per-connection list of active extensions, and also takes care of sending the extension callback a destroy message at close-time. When the extensions are instantiated, a private buffer is also allocated and destroyed by the library, so it's easy to maintain per-connection extension private data. Currently, only simple extension names without params are supported, well, no extensions are defined that need them yet. Each active extension gets an opportunity to do buffer rewriting or replacement in turn before any incoming packet is parsed and after each outgoing packet is parsed via callbacks into the extension-specific code. -Andy From Simo.Veikkolainen@nokia.com Mon Mar 7 00:30:47 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF5628C0DE for ; Mon, 7 Mar 2011 00:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlbZ0zPkklKU for ; Mon, 7 Mar 2011 00:30:46 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id AAB6528B797 for ; Mon, 7 Mar 2011 00:30:38 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p278UnVo027720; Mon, 7 Mar 2011 10:31:07 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Mar 2011 10:30:52 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 7 Mar 2011 09:30:52 +0100 Received: from 008-AM1MPN1-002.mgdnok.nokia.com ([169.254.2.164]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0270.002; Mon, 7 Mar 2011 09:30:51 +0100 From: To: Thread-Topic: [hybi] Hello frames? Thread-Index: AQHL144TzEmbNhe9s0+0y2qPkkKHD5QXe7uAgAAkEwCAAE0vgIAAA14AgAB3ORCAACM3gIAJB+OA Date: Mon, 7 Mar 2011 08:30:51 +0000 Message-ID: References: <20110301060349.GC9463@1wt.eu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.23.234] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 07 Mar 2011 08:30:52.0844 (UTC) FILETIME=[F8934EC0:01CBDCA1] X-Nokia-AV: Clean Cc: hybi@ietf.org, Gabriel.Montenegro@microsoft.com, gregw@intalio.com Subject: Re: [hybi] Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 08:30:47 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBleHQgSm9obiBUYW1wbGluIFtt YWlsdG86amF0QGdvb2dsZS5jb21dDQo+IFNlbnQ6IDAxIE1hcmNoLCAyMDExIDE3OjI5DQo+IFRv OiBWZWlra29sYWluZW4gU2ltbyAoTm9raWEtTVMvSGVsc2lua2kpDQo+IENjOiBncmVnd0BpbnRh bGlvLmNvbTsgd0Axd3QuZXU7IGh5YmlAaWV0Zi5vcmc7DQo+IEdhYnJpZWwuTW9udGVuZWdyb0Bt aWNyb3NvZnQuY29tDQo+IFN1YmplY3Q6IFJlOiBbaHliaV0gSGVsbG8gZnJhbWVzPw0KPiANCj4g T24gVHVlLCBNYXIgMSwgMjAxMSBhdCA3OjQ5IEFNLCAgPFNpbW8uVmVpa2tvbGFpbmVuQG5va2lh LmNvbT4gd3JvdGU6DQo+ID4gQmVpbmcgYWJsZSB0byB1c2UgYSBzaW5nbGUgaGVhcnRiZWF0IGZv ciBtdWx0aXBsZSB3ZWJzb2NrZXQNCj4gY29ubmVjdGlvbnMNCj4gPiBtaWdodCBhbHNvIGJlIGJl bmVmaWNpYWwsIGJ1dCBub3QgdGhhdCBjcml0aWNhbC4gSW4gY2VsbHVsYXINCj4gbmV0d29ya3Ms IHdha2luZw0KPiA+IHVwIHRoZSByYWRpbyBmcmVxdWVudGx5IGlzIGNsZWFybHkgd29yc2UgdGhh biBzZW5kaW5nIG91dCBzb21lIG1vcmUNCj4gPiBieXRlcyBvbmNlIHRoZSByYWRpbyBpcyBvbi4g Q2xldmVyIG9wZXJhdGluZyBzeXN0ZW1zIG1pZ2h0IGFsc28gb2ZmZXINCj4gYW4NCj4gPiBBUEkg Zm9yIHF1ZXVpbmcgbXVsdGlwbGUgaGVhcnRiZWF0IG1lc3NhZ2VzIGFuZCBzZW5kaW5nIHRoZW0g b3V0IGF0DQo+ID4gb25lIGdvLg0KPiANCj4gSSBkb24ndCBzZWUgaG93IHRoZSBPUyBjYW4gZ2V0 IGludm9sdmVkIGluIGl0IC0tIGltYWdpbmUgdGhlIG1vYmlsZQ0KPiBicm93c2VyIGhhcyAxMCBh cHBzIHJ1bm5pbmcsIGFuZCBlYWNoIG9mIHRoZW0gaGF2ZSBhIGhlYXJiZWF0IGludGVydmFsDQo+ IG9mIDYwcy4gIElmIHRoZXkgaGFwcGVuIHRvIGdldCBzdGFydGVkIGF0IHJlZ3VsYXIgaW50ZXJ2 YWxzLCB5b3UgY291bGQNCj4gd2luZCB1cCB3aXRoIHRoZSBjYXNlIG9mIGhhdmluZyB0byBzZW5k IGEga2VlcGFsaXZlIGZyYW1lIGV2ZXJ5IDYNCj4gc2Vjb25kcy4gIFRoZSBPUyBvbmx5IGtub3dz IHRoYXQgcGFja2V0cyBhcmUgYmVpbmcgc2VudCBvdmVyIHNlcGFyYXRlDQo+IFRDUCBjb25uZWN0 aW9ucyAtLSBob3cgZG9lcyBpdCBrbm93IGl0IGNhbiBkZWxheSBzb21lIG9mIHRob3NlIHRvDQo+ IGF2b2lkIHBvd2VyaW5nIHVwIHRoZSByYWRpbz8gIElmIGl0IGRlbGF5cyBzb21lIG9mIHRoZW0g dG9vIG11Y2gsIHRoZQ0KPiBjb25uZWN0aW9uIGNvdWxkIGJlIGRyb3BwZWQgYXMgd2VsbC4NCg0K Q29taW5nIGJhY2sgdG8gdGhpcy4uLiBVc2luZyB0aGVzZSBraW5kIG9mIEFQSSByZXF1aXJlcyBz b21lIGNvLW9wZXJhdGlvbiBmcm9tIHRoZSBhcHBsaWNhdGlvbiBhcyB3ZWxsLCBhcyBpdCB3b3Vs ZCB0eXBpY2FsbHkgbmVlZCB0byBkZWZpbmUgYSB0b2xlcmFuY2UgcmFuZ2Ugd2l0aGluIHdoaWNo IHRoZSBoZWFydGJlYXQgY2FuIGJlIHNlbnQuIE1heWJlIG5vdCBwZXJmZWN0IGJ1dCBtaWdodCBz YXZlIHNvbWUgcG93ZXIgb24gYSBtb2JpbGUuDQoNClNpbW8NCg0KPiBJIHJlYWxseSB0aGluayBh bGwgb2YgdGhpcyBpcyBhIGxvdCBtb3JlIGNvbXBsaWNhdGVkIHRvIGdldCByaWdodCwgYW5kDQo+ IEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIHRyeSBhbmQgcHV0IGl0IGludG8gdGhlIGJhc2Ugc3Bl YyB3aXRoIG5vDQo+IGV4cGVyaWVuY2Ugb2YgZGVwbG95aW5nIFdlYlNvY2tldCBvbiBtb2JpbGUg ZGV2aWNlcyB0byBzZWUgaG93IGl0IGlzDQo+IGdvaW5nIHRvIGdldCB1c2VkLg0KPiANCj4gQWxz bywgYXBwbGljYXRpb25zIGFyZSBsaWtlbHkgdG8gd2FudCB0aGVpciBvd24gdGltZW91dCwgc28g aWYgeW91DQo+IGRvbid0IGV4cG9zZSBzb21lIHdheSBmb3IgYXBwcyB0byBjb250cm9sIHRoZSBp bnRlcnZhbCBhbmQgd2hhdA0KPiBhY3R1YWxseSBoYXBwZW5zIG9uIGl0IChwZXJoYXBzIGEgbm8t b3AgY2FsbCB0byB0aGVpciBzZXJ2ZXIpLCB0aGVuDQo+IHlvdSBhcmUgbGlrZWx5IHRvIHdpbmQg dXAgd2l0aCBtdWx0aXBsZSBsYXllcnMgb2YgaGVhcnRiZWF0IG1lc3NhZ2VzLg0KPiANCj4gLS0N Cj4gSm9obiBBLiBUYW1wbGluDQo+IFNvZnR3YXJlIEVuZ2luZWVyIChHV1QpLCBHb29nbGUNCg== From mcmanus@ducksong.com Mon Mar 7 09:47:23 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F1B3A680F for ; Mon, 7 Mar 2011 09:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhfieU+GT9fC for ; Mon, 7 Mar 2011 09:47:23 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id EEF463A67DA for ; Mon, 7 Mar 2011 09:47:22 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id D27581043E; Mon, 7 Mar 2011 12:48:35 -0500 (EST) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id C5467102A5 for ; Mon, 7 Mar 2011 12:48:31 -0500 (EST) From: "Pat McManus @Mozilla" To: hybi Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Mar 2011 12:48:37 -0500 Message-ID: <1299520117.2606.130.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Subject: [hybi] interop tests - fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 17:47:24 -0000 I'm looking to test with a server that generates and sends fragmented messages. Anyone implement that? -- http://www.getfirefox.com/ From gregw@intalio.com Mon Mar 7 12:46:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C13203A680A for ; Mon, 7 Mar 2011 12:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgUa2eYX3q5l for ; Mon, 7 Mar 2011 12:46:23 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 598B43A67D2 for ; Mon, 7 Mar 2011 12:46:23 -0800 (PST) Received: by vxg33 with SMTP id 33so4811924vxg.31 for ; Mon, 07 Mar 2011 12:47:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.180.166 with SMTP id dp6mr2535865vdc.63.1299530855366; Mon, 07 Mar 2011 12:47:35 -0800 (PST) Sender: gregw@intalio.com Received: by 10.52.169.39 with HTTP; Mon, 7 Mar 2011 12:47:35 -0800 (PST) In-Reply-To: <1299520117.2606.130.camel@ds9.ducksong.com> References: <1299520117.2606.130.camel@ds9.ducksong.com> Date: Tue, 8 Mar 2011 07:47:35 +1100 X-Google-Sender-Auth: sbFd_DOKhKK8wmdSYCtRUe61oAY Message-ID: From: Greg Wilkins To: "Pat McManus @Mozilla" Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi Subject: Re: [hybi] interop tests - fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 20:46:24 -0000 Pat, The jetty server 7.3.1.v20110307 has API to will send/receive fragments, but no test app that will do it out of the box, other than test harnesses. Ping me on email or #jetty on irc.freenode.net if you have a question about usage cheers On 8 March 2011 04:48, Pat McManus @Mozilla wrote: > I'm looking to test with a server that generates and sends fragmented > messages. Anyone implement that? > > > -- > http://www.getfirefox.com/ > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From andy.warmcat.com@googlemail.com Mon Mar 7 13:48:45 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2400E3A686D for ; Mon, 7 Mar 2011 13:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrWRBQEIcVYh for ; Mon, 7 Mar 2011 13:48:44 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 890463A684A for ; Mon, 7 Mar 2011 13:48:40 -0800 (PST) Received: by wyb42 with SMTP id 42so5076286wyb.31 for ; Mon, 07 Mar 2011 13:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IggT/yWDFppZkCG44GxTA9xDB7XIDH034xfskNvHotw=; b=oaNjETzzMUXXfdO00NcJLpKg/3IPvb1JXK0t6jlEu3j0Jw2/Crcdb5aspl4PgKy+XI dPxSsv2JWG9JpwpAdi5wt08b/Tz4lxTeTli38LjrxNXD/xdV40LFMwXa+7Kr+WKfIx7/ 0cC+AyeFrsAohEdAHEe+sefGZTDjPDWhYqo4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Nz506tgyjoTAxj/k+GcvdqOTxqdlwVYyADFaKH6gCfE7HgZXTPA7MTxnA9T1OEKWMX 1LYGpk5er2AZnM3deP7M1s6AxKWTREEQI9CsEk8M3PrsI95l6TCHMLLNiUEHK7iBOD81 udmWf6oKF0ddGIP25mNN9IG25OaGj4hBzvB9U= Received: by 10.227.71.197 with SMTP id i5mr3976247wbj.113.1299534593412; Mon, 07 Mar 2011 13:49:53 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id u9sm29895wbg.0.2011.03.07.13.49.50 (version=SSLv3 cipher=OTHER); Mon, 07 Mar 2011 13:49:52 -0800 (PST) Sender: Andy Green Message-ID: <4D7552FD.9090002@warmcat.com> Date: Mon, 07 Mar 2011 21:49:49 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Pat McManus @Mozilla" References: <1299520117.2606.130.camel@ds9.ducksong.com> In-Reply-To: <1299520117.2606.130.camel@ds9.ducksong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi Subject: Re: [hybi] interop tests - fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 21:48:45 -0000 On 03/07/2011 05:48 PM, Somebody in the thread at some point said: > I'm looking to test with a server that generates and sends fragmented > messages. Anyone implement that? libwebsockets supports fragmentation now, I added a fragmentation test server and client test applet to confirm it's at least internally consistent. Greg I dunno if you're interested to knock something similar up for Jetty like you did for the test ping applet? At the moment I had the test app turn off compression on the link. http://git.warmcat.com/cgi-bin/cgit/libwebsockets/ Here's the README about it --> Fraggle test app ---------------- By default it runs in server mode $ libwebsockets-test-fraggle libwebsockets test fraggle (C) Copyright 2010-2011 Andy Green licensed under LGPL2.1 Compiled with SSL support, not using it Listening on port 7681 server sees client connect accepted v06 connection Spamming 360 random fragments Spamming session over, len = 371913. sum = 0x2D3C0AE Spamming 895 random fragments Spamming session over, len = 875970. sum = 0x6A74DA1 ... You need to run a second session in client mode, you have to give the -c switch and the server address at least: $ libwebsockets-test-fraggle -c localhost libwebsockets test fraggle (C) Copyright 2010-2011 Andy Green licensed under LGPL2.1 Client mode Connecting to localhost:7681 denied deflate-stream extension handshake OK for protocol fraggle-protocol client connects to server EOM received 371913 correctly from 360 fragments EOM received 875970 correctly from 895 fragments EOM received 247140 correctly from 258 fragments EOM received 695451 correctly from 692 fragments ... The fraggle test sends a random number up to 1024 fragmented websocket frames each of a random size between 1 and 2001 bytes in a single message, then sends a checksum and starts sending a new randomly sized and fragmented message. The fraggle test client receives the same message fragments and computes the same checksum using websocket framing to see when the message has ended. It then accepts the server checksum message and compares that to its checksum. -Andy From gregw@intalio.com Mon Mar 7 14:10:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8D03A687B for ; Mon, 7 Mar 2011 14:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5Twp0XRc0yw for ; Mon, 7 Mar 2011 14:10:24 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 78B443A682C for ; Mon, 7 Mar 2011 14:10:24 -0800 (PST) Received: by vws6 with SMTP id 6so4867792vws.31 for ; Mon, 07 Mar 2011 14:11:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.0.169 with SMTP id 9mr6156955vdf.303.1299535897354; Mon, 07 Mar 2011 14:11:37 -0800 (PST) Sender: gregw@intalio.com Received: by 10.52.169.39 with HTTP; Mon, 7 Mar 2011 14:11:37 -0800 (PST) In-Reply-To: <4D7552FD.9090002@warmcat.com> References: <1299520117.2606.130.camel@ds9.ducksong.com> <4D7552FD.9090002@warmcat.com> Date: Tue, 8 Mar 2011 09:11:37 +1100 X-Google-Sender-Auth: bYHGl4fgqmN0-b7OiKShl-iv3hk Message-ID: From: Greg Wilkins To: Andy Green Content-Type: multipart/alternative; boundary=20cf304346d688e59d049debc769 Cc: hybi Subject: Re: [hybi] interop tests - fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 22:10:26 -0000 --20cf304346d688e59d049debc769 Content-Type: text/plain; charset=ISO-8859-1 Andy, I will write a test client and server to match. Actually, I think we should come up with a list of standardized sub-protocol names that match to tests we can do for compatibility, and then also test production servers don't accidentally deploy tests like echo. I noticed you have a protocol name of lws-mirror-protocol for an echo server. How about: org.ietf.websocket.test-echo - echo all frames org.ietf.websocket.test-echo-assemble - echo messages after assembling all fragments org.ietf.websocket.test-echo-fragment - echo frames randomly fragmented org.ietf.websocket.test-consume - consume all messages. Every 1s send a text message formatted as follows "frames=%d messages=%d bytes=%d binary=%d" org.ietf.websocket.test-produce - produce messages of random size and fragmentation It would be really handy if protocol names could be parameterised, so in the last instance we could do something like: org.ietf.websocket. test-produce;minMsg=16;maxMsg=4096;fragment=true;pause=50ms we could then also just have test-echo and the assemble and fragment behaviours could be parameters. cheers On 8 March 2011 08:49, Andy Green wrote: > On 03/07/2011 05:48 PM, Somebody in the thread at some point said: >> >> I'm looking to test with a server that generates and sends fragmented >> messages. Anyone implement that? > > libwebsockets supports fragmentation now, I added a fragmentation test > server and client test applet to confirm it's at least internally > consistent. Greg I dunno if you're interested to knock something similar up > for Jetty like you did for the test ping applet? > > At the moment I had the test app turn off compression on the link. > > http://git.warmcat.com/cgi-bin/cgit/libwebsockets/ > > Here's the README about it --> > > Fraggle test app > ---------------- > > By default it runs in server mode > > $ libwebsockets-test-fraggle > libwebsockets test fraggle > (C) Copyright 2010-2011 Andy Green licensed under LGPL2.1 > Compiled with SSL support, not using it > Listening on port 7681 > server sees client connect > accepted v06 connection > Spamming 360 random fragments > Spamming session over, len = 371913. sum = 0x2D3C0AE > Spamming 895 random fragments > Spamming session over, len = 875970. sum = 0x6A74DA1 > ... > > You need to run a second session in client mode, you have to > give the -c switch and the server address at least: > > $ libwebsockets-test-fraggle -c localhost > libwebsockets test fraggle > (C) Copyright 2010-2011 Andy Green licensed under LGPL2.1 > Client mode > Connecting to localhost:7681 > denied deflate-stream extension > handshake OK for protocol fraggle-protocol > client connects to server > EOM received 371913 correctly from 360 fragments > EOM received 875970 correctly from 895 fragments > EOM received 247140 correctly from 258 fragments > EOM received 695451 correctly from 692 fragments > ... > > The fraggle test sends a random number up to 1024 fragmented websocket > frames > each of a random size between 1 and 2001 bytes in a single message, then > sends > a checksum and starts sending a new randomly sized and fragmented message. > > The fraggle test client receives the same message fragments and computes the > same checksum using websocket framing to see when the message has ended. It > then accepts the server checksum message and compares that to its checksum. > > -Andy > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --20cf304346d688e59d049debc769 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Andy,

I will write a test client and server to match.

Act= ually, I think we should come up with a list of standardized sub-protocol n= ames that match to tests we can do for compatibility, and then also test pr= oduction servers don't accidentally deploy tests like echo.

I noticed you have a protocol name of =A0lws-mirror-protocol =A0for an = echo server.

How about:

org.ietf.webs= ocket.test-echo =A0 =A0 =A0 =A0 =A0 =A0=A0 - echo all frames
org.ietf.websocket.test-echo-assemble = =A0 =A0 - echo messages after assembling all fragments
org.ietf.websocket.test-echo-fragment = =A0 =A0 - echo frames randomly fragmented

org.ietf.websocket.test-consume =A0 =A0 =A0 =A0=A0=A0 - consume = all messages. Every 1s send a text message formatted as follows "frame= s=3D%d messages=3D%d bytes=3D%d binary=3D%d"
org.ietf.websock= et.test-produce= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - produce messages of random size and fragme= ntation


It would be really handy if protocol names could be paramete= rised, so in the last instance we could do something like:

org.ietf.websock= et.test-produce;= minMsg=3D16;maxMsg=3D4096;fragment=3Dtrue;pause=3D50ms

we cou= ld then also just have test-echo and the assemble and fragment behaviours c= ould be parameters.

cheers



On 8 March 2011 08:49, Andy Green <andy@warmcat.com> wrote:
> On 03/07/2= 011 05:48 PM, Somebody in the thread at some point said:
>>
>= ;> I'm looking to test with a server that generates and sends fragme= nted
>> messages. Anyone implement that?
>
> libwebsockets sup= ports fragmentation now, I added a fragmentation test
> server and cl= ient test applet to confirm it's at least internally
> consistent= . =A0Greg I dunno if you're interested to knock something similar up > for Jetty like you did for the test ping applet?
>
> At th= e moment I had the test app turn off compression on the link.
>
&g= t; http://gi= t.warmcat.com/cgi-bin/cgit/libwebsockets/
>
> Here's the README about it -->
>
> Fraggle = test app
> ----------------
>
> By default it runs in ser= ver mode
>
> $ libwebsockets-test-fraggle
> libwebsockets= test fraggle
> (C) Copyright 2010-2011 Andy Green <andy@warmcat.com> licensed under LGPL2.1
> =A0Compiled wi= th SSL support, not using it
> =A0Listening on port 7681
> serv= er sees client connect
> accepted v06 connection
> Spamming 360 random fragments
> = Spamming session over, len =3D 371913. sum =3D 0x2D3C0AE
> Spamming 8= 95 random fragments
> Spamming session over, len =3D 875970. sum =3D = 0x6A74DA1
> ...
>
> You need to run a second session in client mode, y= ou have to
> give the -c switch and the server address at least:
&= gt;
> $ libwebsockets-test-fraggle -c localhost
> libwebsockets= test fraggle
> (C) Copyright 2010-2011 Andy Green <andy@warmcat.com> licensed under LGPL2.1
> =A0Client mode=
> Connecting to localhost:7681
> denied deflate-stream extensi= on
> handshake OK for protocol fraggle-protocol
> client connects to = server
> EOM received 371913 correctly from 360 fragments
> EOM= received 875970 correctly from 895 fragments
> EOM received 247140 c= orrectly from 258 fragments
> EOM received 695451 correctly from 692 fragments
> ...
>> The fraggle test sends a random number up to 1024 fragmented websock= et
> frames
> each of a random size between 1 and 2001 bytes in= a single message, then
> sends
> a checksum and starts sending a new randomly sized and f= ragmented message.
>
> The fraggle test client receives the sam= e message fragments and computes the
> same checksum using websocket = framing to see when the message has ended. =A0It
> then accepts the server checksum message and compares that to its chec= ksum.
>
> -Andy
> _______________________________________= ________
> hybi mailing list
> hybi@ietf.org
> https://www.iet= f.org/mailman/listinfo/hybi
>

--20cf304346d688e59d049debc769-- From Gabriel.Montenegro@microsoft.com Mon Mar 7 16:00:14 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849D028C160 for ; Mon, 7 Mar 2011 16:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.51 X-Spam-Level: X-Spam-Status: No, score=-10.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUEt+8I8CVbo for ; Mon, 7 Mar 2011 16:00:13 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 142FC28C156 for ; Mon, 7 Mar 2011 16:00:13 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 7 Mar 2011 16:01:27 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.270.2; Mon, 7 Mar 2011 16:01:27 -0800 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.139]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Mon, 7 Mar 2011 16:01:26 -0800 From: Gabriel Montenegro To: Andy Green , "Yutaka_Takeda@PlayStation.Sony.Com" Thread-Topic: [hybi] Keep-Alive, was: Hello frames? Thread-Index: AQHL23iiVSOisr8ziE2QdN/nEnzod5QgDr4AgACC6YCAAf3wQA== Date: Tue, 8 Mar 2011 00:01:25 +0000 Message-ID: References: <4D735465.9060706@warmcat.com> In-Reply-To: <4D735465.9060706@warmcat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] Keep-Alive, was: Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 00:00:14 -0000 > On 03/06/2011 01:42 AM, Somebody in the thread at some point said: > > Sec-WebSocket-KeepAlive: interval=3D120, timeout=3D10 [gab] This issue is not specific to websockets, so it seems to me that it s= hould be addressed in a more general fashion, otherwise there will be more = keepalives than necessary (if there is independent treatment instead of coo= rdination among websockets, comet, etc). I'd say we only keep the basic mec= hanisms in the draft (Ping/Pong, unsolicited Pong), and leave the rest for = another separate draft which could be pursued either in HyBi or elsewhere.= =20 From gregw@intalio.com Mon Mar 7 19:56:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BAF93A68DB for ; Mon, 7 Mar 2011 19:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4YgcH6bOn0M for ; Mon, 7 Mar 2011 19:56:47 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B08CD3A67CF for ; Mon, 7 Mar 2011 19:56:47 -0800 (PST) Received: by vws6 with SMTP id 6so5122975vws.31 for ; Mon, 07 Mar 2011 19:58:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.75.231 with SMTP id f7mr3202569vdw.143.1299556681150; Mon, 07 Mar 2011 19:58:01 -0800 (PST) Sender: gregw@intalio.com Received: by 10.52.169.39 with HTTP; Mon, 7 Mar 2011 19:58:01 -0800 (PST) In-Reply-To: References: <1299520117.2606.130.camel@ds9.ducksong.com> <4D7552FD.9090002@warmcat.com> Date: Tue, 8 Mar 2011 14:58:01 +1100 X-Google-Sender-Auth: tjmwBLe91uwyE053jgdVAw0FUU0 Message-ID: From: Greg Wilkins To: Andy Green Content-Type: multipart/alternative; boundary=20cf3071cc525872ce049df09ef6 Cc: hybi Subject: Re: [hybi] interop tests - fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 03:56:48 -0000 --20cf3071cc525872ce049df09ef6 Content-Type: text/plain; charset=ISO-8859-1 On 8 March 2011 09:11, Greg Wilkins wrote: > How about: > > org.ietf.websocket.test-echo - echo all frames > org.ietf.websocket.test-echo-assemble - echo messages after assembling > all fragments > org.ietf.websocket.test-echo-fragment - echo frames randomly > fragmented > > org.ietf.websocket.test-consume - consume all messages. Every 1s > send a text message formatted as follows "frames=%d messages=%d bytes=%d > binary=%d" > org.ietf.websocket.test-produce - produce messages of random > size and fragmentation > > > Also org.ietf.websocket.test-echo-broadcast - echo all frames to all connected websockets --20cf3071cc525872ce049df09ef6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 8 March 2011 09:11, Greg Wilkins <gregw@webtide.com> wrote:
How about:

org.ietf.websocket.test-echo =A0 = =A0 =A0 =A0 =A0 =A0=A0 - echo all frames
org.ietf.websocket.test-echo-assemble =A0 = =A0 - echo messages after assembling all fragments
org.ietf.websocket.test-echo-fragment =A0 = =A0 - echo frames randomly fragmented

org.ietf.websocket.test-consume =A0 =A0 =A0 =A0=A0=A0 - consume all me= ssages. Every 1s send a text message formatted as follows "frames=3D%d= messages=3D%d bytes=3D%d binary=3D%d"
org.ietf.websocket= .test-produce=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 - produce messages of random size and fragmenta= tion



Also

=A0=A0 org.= ietf.websocket.test-echo-broadcast =A0 - echo all frames to all connected w= ebsockets
 --20cf3071cc525872ce049df09ef6-- From Yutaka_Takeda@PlayStation.Sony.Com Mon Mar 7 19:59:43 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 046153A68DB for ; Mon, 7 Mar 2011 19:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.012 X-Spam-Level: X-Spam-Status: No, score=-6.012 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rklw8SCAshLX for ; Mon, 7 Mar 2011 19:59:41 -0800 (PST) Received: from paris.playstation.sony.com (nat.playstation.sony.com [69.36.131.254]) by core3.amsl.com (Postfix) with ESMTP id DAE613A67CF for ; Mon, 7 Mar 2011 19:59:41 -0800 (PST) Received: from constantine.playstation.sony.com ([162.49.67.15]) by paris.playstation.sony.com (Lotus Domino Release 8.5.1FP5) with ESMTP id 2011030720005541-171472 ; Mon, 7 Mar 2011 20:00:55 -0800 In-Reply-To: To: Gabriel Montenegro MIME-Version: 1.0 X-KeepSent: 5CADDE8E:0EC11747-8825784D:00108E1C; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Yutaka_Takeda@PlayStation.Sony.Com Date: Mon, 7 Mar 2011 20:00:57 -0800 X-MIMETrack: Serialize by Router on SCEA919ML04/SCEA(Release 8.5.1FP3|May 23, 2010) at 03/07/2011 08:00:55 PM, Serialize complete at 03/07/2011 08:00:55 PM, Itemize by SMTP Server on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/07/2011 08:00:55 PM, Serialize by Router on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/07/2011 08:00:56 PM, Serialize complete at 03/07/2011 08:00:56 PM Content-Type: multipart/alternative; boundary="=_alternative 001610298825784D_=" Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] Keep-Alive, was: Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 03:59:43 -0000 This is a multipart message in MIME format. --=_alternative 001610298825784D_= Content-Type: text/plain; charset="US-ASCII" > > On 03/06/2011 01:42 AM, Somebody in the thread at some point said: > > > Sec-WebSocket-KeepAlive: interval=120, timeout=10 > > [gab] This issue is not specific to websockets, so it seems to me > that it should be addressed in a more general fashion, otherwise Yes, I totally agree. We all wish there was a way to reliably keep TCP connection open in a generic way... > there will be more keepalives than necessary (if there is > independent treatment instead of coordination among websockets, > comet, etc). If some negotiation is desired, though, then it would be protocol specific, wouldn't it? > I'd say we only keep the basic mechanisms in the draft > (Ping/Pong, unsolicited Pong), and leave the rest for another > separate draft which could be pursued either in HyBi or elsewhere. I understand, getting the base protocol out asap is most critical for now, and addressing this with another draft is fine by me. With my implementer's hat on, I'd still hope WS-layer could flexibly and (more) reliably handle the connection lifetime before applications start implementing their own arbitrary keep-alives, which could be a mess and/or such a burden for lazy developers. Best. - Yutaka --=_alternative 001610298825784D_= Content-Type: text/html; charset="US-ASCII"

> > On 03/06/2011 01:42 AM, Somebody in the thread at some point said:
> > > Sec-WebSocket-KeepAlive: interval=120, timeout=10
>
> [gab] This issue is not specific to websockets, so it seems to me
> that it should be addressed in a more general fashion, otherwise

Yes, I totally agree. We all wish there was a way to reliably keep TCP
connection open in a generic way...
 
> there will be more keepalives than necessary (if there is
> independent treatment instead of coordination among websockets,
> comet, etc).

If some negotiation is desired, though, then it would be protocol
specific, wouldn't it?

> I'd say we only keep the basic mechanisms in the draft
> (Ping/Pong, unsolicited Pong), and leave the rest for another
> separate draft which could be pursued either in HyBi or elsewhere.

I understand, getting the base protocol out asap is most critical
for now, and addressing this with another draft is fine by me.

With my implementer's hat on, I'd still hope WS-layer could flexibly
and (more) reliably handle the connection lifetime
before applications start implementing their own arbitrary
keep-alives, which could be a mess and/or such a burden for lazy
developers.


Best.
- Yutaka --=_alternative 001610298825784D_=-- From gregw@intalio.com Mon Mar 7 20:05:45 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA5A3A68DA for ; Mon, 7 Mar 2011 20:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kdj9vsmLhiOz for ; Mon, 7 Mar 2011 20:05:43 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id B237B3A67CF for ; Mon, 7 Mar 2011 20:05:43 -0800 (PST) Received: by vxg33 with SMTP id 33so5155258vxg.31 for ; Mon, 07 Mar 2011 20:06:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.69.46 with SMTP id b14mr1152714vdu.103.1299557217813; Mon, 07 Mar 2011 20:06:57 -0800 (PST) Received: by 10.52.169.39 with HTTP; Mon, 7 Mar 2011 20:06:57 -0800 (PST) In-Reply-To: References: <4D735465.9060706@warmcat.com> Date: Tue, 8 Mar 2011 15:06:57 +1100 Message-ID: From: Greg Wilkins To: Gabriel Montenegro Content-Type: multipart/alternative; boundary=20cf307d03ba5544e6049df0be7e Cc: "Simo.Veikkolainen@nokia.com" , "hybi@ietf.org" , "Yutaka_Takeda@PlayStation.Sony.Com" Subject: Re: [hybi] Keep-Alive, was: Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 04:05:45 -0000 --20cf307d03ba5544e6049df0be7e Content-Type: text/plain; charset=ISO-8859-1 On 8 March 2011 11:01, Gabriel Montenegro wrote: > > On 03/06/2011 01:42 AM, Somebody in the thread at some point said: > > > Sec-WebSocket-KeepAlive: interval=120, timeout=10 > > [gab] This issue is not specific to websockets, so it seems to me that it > should be addressed in a more general fashion, the negotiation/declaration of connection timeouts can indeed be done more generically and I hope that some common headers for that can be agreed. But the actual keep alive process, once idle times are known, will have to protocol specific. > I'd say we only keep the basic mechanisms in the draft (Ping/Pong, > unsolicited Pong), and leave the rest for another separate draft which could > be pursued either in HyBi or elsewhere. > I think we keep the basic mechanisms in the base protocol, but that we have a standard extension for keep-alive in the draft, so as to prevent bespoke solutions being developed and widely deployed. cheers --20cf307d03ba5544e6049df0be7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 8 March 2011 11:01, Gabriel Montenegr= o <Gabriel.Montenegro@microsoft.com> wrote:
> On 03/06/2011 01:42 AM, Somebody in the thread at so= me point said:
> > Sec-WebSocket-KeepAlive: interval=3D120, = timeout=3D10

[gab] This issue is not specific to websockets, so it seems to me tha= t it should be addressed in a more general fashion,

t= he negotiation/declaration of connection timeouts can indeed be done more g= enerically and I hope that some common headers for that can be agreed.

But the actual keep alive process, once idle times are known, will have= to protocol specific.

=A0
=A0I'd say we only keep the basic mechanisms in the draft (Ping/Pong, u= nsolicited Pong), and leave the rest for another separate draft which could= be pursued either in HyBi or elsewhere.

I think we keep the basic mechanisms in the base pro= tocol, but that we have a standard extension for keep-alive in the draft, s= o as to prevent bespoke solutions being developed and widely deployed.

cheers

--20cf307d03ba5544e6049df0be7e-- From toni.ruottu@gmail.com Tue Mar 8 05:33:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563C03A6843 for ; Tue, 8 Mar 2011 05:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsOxZ3D597kW for ; Tue, 8 Mar 2011 05:33:12 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 7CD823A67A8 for ; Tue, 8 Mar 2011 05:33:12 -0800 (PST) Received: by gxk5 with SMTP id 5so2599179gxk.31 for ; Tue, 08 Mar 2011 05:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=8ZcL55apX6QoUciXkVbOKIGma5pKST+LnIhHV5hU88w=; b=pP33qwfCwe8ITk1khEAI9KKClQdwODztFso3x1WLKpJjd7Mb411tAN7ow7kefekMGn ERZdBiXhWWPZFhDVb2AMc2ehZCsObofn73y5YL00m3nzht35GMASje/hKQpJn5th1ddz dFQz/he9wQpF15tRCQU70bTjaMRN5+OczooT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=Jcynd+S9HMpO67L283+XzFXKyDhBaUy8FWkoWQF5TMy/FobTKDyYCTbPDudATBbjfm KolAlJus9HlPiYB4I5CLxmkaAyQQ6j7i45VuxL6BUA4PjEimvbIxq2IBrFCI93rT1ZjS 2n+dlcNjKgdLd44FRzPXy5sYS+xyxqfERlyJk= MIME-Version: 1.0 Received: by 10.147.30.23 with SMTP id h23mr7482728yaj.23.1299591266931; Tue, 08 Mar 2011 05:34:26 -0800 (PST) Sender: toni.ruottu@gmail.com Received: by 10.147.39.7 with HTTP; Tue, 8 Mar 2011 05:34:26 -0800 (PST) Date: Tue, 8 Mar 2011 15:34:26 +0200 X-Google-Sender-Auth: E2MsFjFMuP_NJ1mceCH-SPy4tng Message-ID: From: Toni Ruottu To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] symmetric masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 13:33:13 -0000 hello In the BrowserSocket project we have been looking at defining a web API for running untrusted WebSocket servers in the browser. I am a bit worried about the one sided masking that has been suggested as a solution for attacks on some web proxies. While the focus of WebSocket discussions so far has not been on running untrusted servers, nothing has prevented adding APIs for it as an afterthought without changing the protocol. If the masking is implemented one way only however, an untrusted server could probably do the same attacks against proxies that clients can currently do. Thus it might make sense to implement the masking in a symmetric manner even if it is not a strict requirement at the moment. --Toni From jat@google.com Tue Mar 8 06:27:35 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2433A688F for ; Tue, 8 Mar 2011 06:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.934 X-Spam-Level: X-Spam-Status: No, score=-105.934 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FWwlHUjJmjI for ; Tue, 8 Mar 2011 06:27:34 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8D1603A6843 for ; Tue, 8 Mar 2011 06:27:34 -0800 (PST) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p28ESmV4025184 for ; Tue, 8 Mar 2011 06:28:49 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299594529; bh=qWlHI6tpRD4oCJyTLAVUo12vKTA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=mtQS07u9vEk0K8ImN15W3YKh1B6q5YKUoZpdU7fX/0yiOCwcgNY0gE2R3TNqAHKtO S0GBPHM/FYtP2ELiQttzg== Received: from ywf9 (ywf9.prod.google.com [10.192.6.9]) by kpbe18.cbf.corp.google.com with ESMTP id p28ESltV023460 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 8 Mar 2011 06:28:47 -0800 Received: by ywf9 with SMTP id 9so2792495ywf.27 for ; Tue, 08 Mar 2011 06:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8hsKt3mZUAUwzCIbOEiFGWmrhypGzMJwnLDjQiyGACs=; b=MekFUSsH3U9/xAJ2ih02RT3ijiJ6zs0mjX/wE+ilEgtP9RShubqm6HR3koZvoI8t8K H+iLQesjg50IFNs/pmWQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=lC5juAVKggzamFtar8OC9Iy1Eq6dRXX7jD0dS+Bq1Ns+YrtAetD4kdNqeXJISFf0Im MXkwiD358OHioJoo5vRQ== Received: by 10.150.170.19 with SMTP id s19mr1400192ybe.67.1299594527105; Tue, 08 Mar 2011 06:28:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Tue, 8 Mar 2011 06:28:27 -0800 (PST) In-Reply-To: References: From: John Tamplin Date: Tue, 8 Mar 2011 09:28:27 -0500 Message-ID: To: Toni Ruottu Content-Type: multipart/alternative; boundary=000e0cd4cc3c23e45b049df96e51 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] symmetric masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 14:27:35 -0000 --000e0cd4cc3c23e45b049df96e51 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 8, 2011 at 8:34 AM, Toni Ruottu wrote: > In the BrowserSocket project we have been looking at defining a web > API for running untrusted WebSocket servers in the browser. I am a bit > worried about the one sided masking that has been suggested as a > solution for attacks on some web proxies. While the focus of WebSocket > discussions so far has not been on running untrusted servers, nothing > has prevented adding APIs for it as an afterthought without changing > the protocol. If the masking is implemented one way only however, an > untrusted server could probably do the same attacks against proxies > that clients can currently do. Thus it might make sense to implement > the masking in a symmetric manner even if it is not a strict > requirement at the moment. > If someone has complete control over the server, obviously they can open raw sockets and send what they like on them, so masking has no impact as they can choose the plaintext to produce whatever stream of bytes they want on the wire. Also, the primary attack masking is directed at, corrupting transparent proxies, requires the request to come from the client side of the proxy. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd4cc3c23e45b049df96e51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 8, 2011 at 8:34 AM, Toni Ruottu <toni.ruottu@iki.fi<= /a>> wrote:
In the BrowserSocket project we have been looking at defining a web
API for running untrusted WebSocket servers in the browser. I am a bit
worried about the one sided masking that has been suggested as a
solution for attacks on some web proxies. While the focus of WebSocket
discussions so far has not been on running untrusted servers, nothing
has prevented adding APIs for it as an afterthought without changing
the protocol. If the masking is implemented one way only however, an
untrusted server could probably do the same attacks against proxies
that clients can currently do. Thus it might make sense to implement
the masking in a symmetric manner even if it is not a strict
requirement at the moment.

If someone h= as complete control over the server, obviously they can open raw sockets an= d send what they like on them, so masking has no impact as they can choose = the plaintext to produce whatever stream of bytes they want on the wire.

Also, the primary attack masking is directed at, corrup= ting transparent proxies, requires the request to come from the client side= of the proxy.=C2=A0

--
John A. Tamplin
Software Engi= neer (GWT), Google
--000e0cd4cc3c23e45b049df96e51-- From andy.warmcat.com@googlemail.com Tue Mar 8 06:31:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E401C3A6859 for ; Tue, 8 Mar 2011 06:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjhX9Fr7zu7h for ; Tue, 8 Mar 2011 06:31:25 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 5E3C83A67BD for ; Tue, 8 Mar 2011 06:31:25 -0800 (PST) Received: by wwi17 with SMTP id 17so1048933wwi.1 for ; Tue, 08 Mar 2011 06:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=V/wivTpVj9DhTeQ90TPga74KCn/3EgHGBB7TCdbJ8y0=; b=okurPSvQrnoSCTAO6zjTDU8JgKlSHNPhKC4lw/z5V41Au6wORNamYVS5b0BujC+s7O auMz11WCHNgoG6UtCHe75zXYm10HSGNgjJN6U47//UKzNiLiLTWQ20AFRU3Ac6TqKOZe RraBw2096uU88IcgMA/cKfPFo1dsJBBmDGhhc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=f++Db6nqxQskvCQDzHGCjBRdEsVX0ywrzwXVXZPlRVES6r+tUJeEbF1BZMxrSWtcq1 GSw1kTVq++NJSfH4y02/xw2UmEFkvGFI5vyzseLu74qj9AYMLcwlT6SWoP3uX05ChlLZ AQc9ecPPhxo/cLf4ANkflonU3V1o/HtF1Jjo0= Received: by 10.227.7.67 with SMTP id c3mr3131982wbc.167.1299594759678; Tue, 08 Mar 2011 06:32:39 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id u9sm599926wbg.18.2011.03.08.06.32.37 (version=SSLv3 cipher=OTHER); Tue, 08 Mar 2011 06:32:38 -0800 (PST) Sender: Andy Green Message-ID: <4D763E05.1060705@warmcat.com> Date: Tue, 08 Mar 2011 14:32:37 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: John Tamplin References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] symmetric masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 14:31:27 -0000 On 03/08/2011 02:28 PM, Somebody in the thread at some point said: Hi - > If someone has complete control over the server, obviously they can open > raw sockets and send what they like on them, so masking has no impact as > they can choose the plaintext to produce whatever stream of bytes they > want on the wire. > > Also, the primary attack masking is directed at, corrupting transparent > proxies, requires the request to come from the client side of the proxy. John this guy's project is to add Websocket serving into browsers. So then, his server traffic is coming from his browser and so on the client side of the proxy. I guess he would like all the browsers to integrate his project, then browsers would be able to issue unmasked packets, if they could get a client to touch their listening socket which seems a whole other problem, but that's his point anyway. -Andy From jat@google.com Tue Mar 8 06:49:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3EE3A67C1 for ; Tue, 8 Mar 2011 06:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.935 X-Spam-Level: X-Spam-Status: No, score=-105.935 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79FCN8LnUDgR for ; Tue, 8 Mar 2011 06:49:23 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 13CDB3A689A for ; Tue, 8 Mar 2011 06:49:22 -0800 (PST) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p28EobWl010511 for ; Tue, 8 Mar 2011 06:50:37 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299595837; bh=Jc+bkagclVHFSDTvxQ2ePiFY+Qk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=FuDkUfKo3oF6uBMCmurFb4X+CkkKR3q242yfDCPeYEo94DCLRLAlxF5CoXVdE4zAE Cs4Y8daMQHl/7FRGRpBsQ== Received: from gyh3 (gyh3.prod.google.com [10.243.50.195]) by hpaq12.eem.corp.google.com with ESMTP id p28Eo1eu001785 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 8 Mar 2011 06:50:35 -0800 Received: by gyh3 with SMTP id 3so2244965gyh.36 for ; Tue, 08 Mar 2011 06:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MI4iVqyYjnScDVnnWBWnjdIsfQqPEnagsQcgl9qBOrc=; b=hrMaEkNJKDL1AECCyIXxW/uBAGsbe2Sn6fOS7TVmgs/EPC4kddwbHbvJ2lEBgau+GJ uXYgsrRkTskypOxF+Qog== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=we1GPCy5I8D8vKPgSNtk/kA7lQxMGA9nh0Ln3MhfM0pWWGUExAU4T5mPa129/zFZpQ DqTs9jz5f7Uua35sUKWQ== Received: by 10.150.209.1 with SMTP id h1mr6051380ybg.181.1299595820248; Tue, 08 Mar 2011 06:50:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Tue, 8 Mar 2011 06:50:00 -0800 (PST) In-Reply-To: <4D763E05.1060705@warmcat.com> References: <4D763E05.1060705@warmcat.com> From: John Tamplin Date: Tue, 8 Mar 2011 09:50:00 -0500 Message-ID: To: Andy Green Content-Type: multipart/alternative; boundary=000e0cd51c9e37b0df049df9bb3e X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] symmetric masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 14:49:24 -0000 --000e0cd51c9e37b0df049df9bb3e Content-Type: text/plain; charset=UTF-8 On Tue, Mar 8, 2011 at 9:32 AM, Andy Green wrote: > John this guy's project is to add Websocket serving into browsers. So > then, his server traffic is coming from his browser and so on the client > side of the proxy. > > I guess he would like all the browsers to integrate his project, then > browsers would be able to issue unmasked packets, if they could get a client > to touch their listening socket which seems a whole other problem, but > that's his point anyway. > Sorry, I missed that the server was running in the browser. In that case, I agree there might be attacks that could be prevented with masking. However, I am not sure the vulnerable transparent intermediary is one of them. Presumably the extension isn't going to allow JS to make arbitrary connections, only respond to inbound WebSocket client connections. It is hard to imagine a configuration of a transparent proxy that would get confused about the side of the conversation it is listening to and start handling client requests from the server side, though I suppose it is possible. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd51c9e37b0df049df9bb3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 8, 2011 at 9:32 AM, Andy Green <andy@warmcat.com&g= t; wrote:
John this guy's project is to add Websocket serving into browsers. =C2= =A0So then, his server traffic is coming from his browser and so on the cli= ent side of the proxy.

I guess he would like all the browsers to integrate his project, then brows= ers would be able to issue unmasked packets, if they could get a client to = touch their listening socket which seems a whole other problem, but that= 9;s his point anyway.

Sorry, I missed that the serv= er was running in the browser. =C2=A0In that case, I agree there might be a= ttacks that could be prevented with masking.

Howev= er, I am not sure the vulnerable transparent intermediary is one of them. = =C2=A0Presumably the extension isn't going to allow JS to make arbitrar= y connections, only respond to inbound WebSocket client connections. =C2=A0= It is hard to imagine a configuration of a transparent proxy that would get= confused about the side of the conversation it is listening to and start h= andling client requests from the server side, though I suppose it is possib= le.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd51c9e37b0df049df9bb3e-- From Yutaka_Takeda@PlayStation.Sony.Com Tue Mar 8 13:02:33 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7EAD3A68D5 for ; Tue, 8 Mar 2011 13:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84cVs-pyiS7A for ; Tue, 8 Mar 2011 13:02:32 -0800 (PST) Received: from paris.playstation.sony.com (nat.playstation.sony.com [69.36.131.254]) by core3.amsl.com (Postfix) with ESMTP id D968D3A67B3 for ; Tue, 8 Mar 2011 13:02:31 -0800 (PST) Received: from constantine.playstation.sony.com ([162.49.67.15]) by paris.playstation.sony.com (Lotus Domino Release 8.5.1FP5) with ESMTP id 2011030813034471-200587 ; Tue, 8 Mar 2011 13:03:44 -0800 In-Reply-To: To: Greg Wilkins MIME-Version: 1.0 X-KeepSent: 9D8A7B48:15DBE238-8825784D:00709D68; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Yutaka_Takeda@PlayStation.Sony.Com Date: Tue, 8 Mar 2011 13:03:41 -0800 X-MIMETrack: Serialize by Router on SCEA919ML04/SCEA(Release 8.5.1FP3|May 23, 2010) at 03/08/2011 01:03:44 PM, Serialize complete at 03/08/2011 01:03:44 PM, Itemize by SMTP Server on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/08/2011 01:03:44 PM, Serialize by Router on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/08/2011 01:03:48 PM, Serialize complete at 03/08/2011 01:03:48 PM Content-Type: multipart/alternative; boundary="=_alternative 0073B2AD8825784D_=" Cc: "hybi@ietf.org" , "Simo.Veikkolainen@nokia.com" , Gabriel Montenegro Subject: Re: [hybi] Keep-Alive, was: Hello frames? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 21:02:33 -0000 This is a multipart message in MIME format. --=_alternative 0073B2AD8825784D_= Content-Type: text/plain; charset="US-ASCII" http://datatracker.ietf.org/doc/draft-thomson-hybi-http-timeout/ Nice move! Particularly, Connection-Timeout header can be reused for WebSocket connection lifetime management and good candidate for a work item to this group. One thing left unclear to me is whether timeout for 'Pong' needs to be defined within WebSocket (either base protocol or extension) as ping/pong is WebSocket specific. - Yutaka > > On 03/06/2011 01:42 AM, Somebody in the thread at some point said: > > > Sec-WebSocket-KeepAlive: interval=120, timeout=10 > [gab] This issue is not specific to websockets, so it seems to me > that it should be addressed in a more general fashion, > > the negotiation/declaration of connection timeouts can indeed be > done more generically and I hope that some common headers for that > can be agreed. > > But the actual keep alive process, once idle times are known, will > have to protocol specific. > > > I'd say we only keep the basic mechanisms in the draft (Ping/Pong, > unsolicited Pong), and leave the rest for another separate draft > which could be pursued either in HyBi or elsewhere. > > I think we keep the basic mechanisms in the base protocol, but that > we have a standard extension for keep-alive in the draft, so as to > prevent bespoke solutions being developed and widely deployed. > > cheers --=_alternative 0073B2AD8825784D_= Content-Type: text/html; charset="US-ASCII"
http://datatracker.ietf.org/doc/draft-thomson-hybi-http-timeout/
Nice move! Particularly, Connection-Timeout header can be reused for WebSocket connection lifetime management and good candidate for a work item to this group.

One thing left unclear to me is whether timeout for 'Pong' needs to be defined within WebSocket (either base protocol or extension) as ping/pong is WebSocket specific.


- Yutaka



> > On 03/06/2011 01:42 AM, Somebody in the thread at some point said:
> > > Sec-WebSocket-KeepAlive: interval=120, timeout=10
> [gab] This issue is not specific to websockets, so it seems to me
> that it should be addressed in a more general fashion,
>
> the negotiation/declaration of connection timeouts can indeed be
> done more generically and I hope that some common headers for that
> can be agreed.
>
> But the actual keep alive process, once idle times are known, will
> have to protocol specific.
>
>  
>  I'd say we only keep the basic mechanisms in the draft (Ping/Pong,
> unsolicited Pong), and leave the rest for another separate draft
> which could be pursued either in HyBi or elsewhere.
>
> I think we keep the basic mechanisms in the base protocol, but that
> we have a standard extension for keep-alive in the draft, so as to
> prevent bespoke solutions being developed and widely deployed.
>
> cheers
 --=_alternative 0073B2AD8825784D_=-- From gregw@intalio.com Tue Mar 8 16:34:33 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42E4F3A67E3 for ; Tue, 8 Mar 2011 16:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKW8k647MVmj for ; Tue, 8 Mar 2011 16:34:32 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 6D5273A67D4 for ; Tue, 8 Mar 2011 16:34:31 -0800 (PST) Received: by vxg33 with SMTP id 33so18132vxg.31 for ; Tue, 08 Mar 2011 16:35:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.75.231 with SMTP id f7mr5027425vdw.143.1299630946692; Tue, 08 Mar 2011 16:35:46 -0800 (PST) Received: by 10.52.169.39 with HTTP; Tue, 8 Mar 2011 16:35:46 -0800 (PST) Date: Wed, 9 Mar 2011 11:35:46 +1100 Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] 1004 message that is too large X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 00:34:33 -0000 Draft 6 says close code 1004 is for 1004 indicates that an endpoint is terminating the connection because it has received a message that is too large However there are two different too large states that are common when handling websocket: a) An individual frame is too large. b) The message size is too large. Either these need separate close codes, or the description needs to be that 1004 can be for a too large frame or message. cheers From gregw@intalio.com Tue Mar 8 20:12:02 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F6BB3A681D for ; Tue, 8 Mar 2011 20:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.122 X-Spam-Level: X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Feo3-30oNrR for ; Tue, 8 Mar 2011 20:12:01 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 286013A6817 for ; Tue, 8 Mar 2011 20:12:00 -0800 (PST) Received: by vxg33 with SMTP id 33so171278vxg.31 for ; Tue, 08 Mar 2011 20:13:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.100.65 with SMTP id ew1mr5199990vdb.183.1299643995581; Tue, 08 Mar 2011 20:13:15 -0800 (PST) Sender: gregw@intalio.com Received: by 10.52.169.39 with HTTP; Tue, 8 Mar 2011 20:13:15 -0800 (PST) In-Reply-To: <4D6FCF1C.3090701@callenish.com> References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> Date: Wed, 9 Mar 2011 15:13:15 +1100 X-Google-Sender-Auth: XTRKTWUkne303WoaRKZU_eP7xkM Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 04:12:02 -0000 Ian, What are your thoughts about this as editor? there does not appear to be any opposed and there is support for Johns original proposal. It would be good to know soon if you think this will be in -07, as it affects the server APIs somewhat. cheers On 4 March 2011 04:25, Bruce Atherton wrote: > On 02/03/2011 11:13 AM, John Tamplin wrote: >> >> My suggestion would be to define a CONTROL opcode, and then for that >> opcode the first byte of the payload defines which control frame is >> present. > > +1. Simply from a design perspective it makes more sense. Text frame, binary > frame, continuation frame, and control frame all feel like the same level of > abstraction. Breaking control down into ping, pong, and close seems like an > abstraction imbalance. And what do you gain by taking this deep-dive on the > control frames? Saving a single byte from a frame that is already tiny? > > Plus there are the other benefits you mention. I just think this makes > sense. > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From gregw@intalio.com Tue Mar 8 20:13:09 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CFE73A6812 for ; Tue, 8 Mar 2011 20:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsM2sapXesGa for ; Tue, 8 Mar 2011 20:13:08 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 4FAA63A6817 for ; Tue, 8 Mar 2011 20:13:08 -0800 (PST) Received: by vxg33 with SMTP id 33so171942vxg.31 for ; Tue, 08 Mar 2011 20:14:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.0.169 with SMTP id 9mr8555415vdf.303.1299644063801; Tue, 08 Mar 2011 20:14:23 -0800 (PST) Received: by 10.52.169.39 with HTTP; Tue, 8 Mar 2011 20:14:23 -0800 (PST) Date: Wed, 9 Mar 2011 15:14:23 +1100 Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] Browser plans? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 04:13:09 -0000 Are any browsers planning to come out with -06 support ? regards From ifette@google.com Tue Mar 8 20:53:03 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F0193A681C for ; Tue, 8 Mar 2011 20:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.509 X-Spam-Level: X-Spam-Status: No, score=-105.509 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5Q+69zcSKvO for ; Tue, 8 Mar 2011 20:53:02 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id DFAB33A6807 for ; Tue, 8 Mar 2011 20:53:01 -0800 (PST) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p294sGlh024238 for ; Tue, 8 Mar 2011 20:54:16 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299646457; bh=2uXfBSKOY4c3sfX5RSHEJIbReGY=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=gNkRQRAKtaBZK1HJS4yVW8fJDB6mN4ktLI6YyXa6JHjPf9S0QXTe9KS/zgApj4HrD 2p2zX3y11aRRHVnCFdJEw== Received: from iwn6 (iwn6.prod.google.com [10.241.68.70]) by wpaz33.hot.corp.google.com with ESMTP id p294sE9U014134 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 8 Mar 2011 20:54:15 -0800 Received: by iwn6 with SMTP id 6so224593iwn.11 for ; Tue, 08 Mar 2011 20:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9/M8P8R/vAzUGVD2uTSfk8K1zM9aVa9e0c1uY21AoP0=; b=ZBpBP0OTmSXNwfSLz8q86cRQ61cl7bS0RLAEb/N5ccCJ5rmXQyplwsBFRmfnYjUaW2 +PqM4gvNdhGCgKxtpOAg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=v+sFv/Sk/SXixtiQ4lTwZz6HEgTYPordm96KlrNlltYRvr8XapGuyQ/2TMigO3luRJ 1ROP07LfdYsOhkoErvxA== MIME-Version: 1.0 Received: by 10.231.195.95 with SMTP id eb31mr4420668ibb.160.1299646454252; Tue, 08 Mar 2011 20:54:14 -0800 (PST) Received: by 10.231.34.131 with HTTP; Tue, 8 Mar 2011 20:54:14 -0800 (PST) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> Date: Tue, 8 Mar 2011 20:54:14 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Greg Wilkins Content-Type: multipart/alternative; boundary=0050450171733d44d2049e0585f0 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 04:53:03 -0000 --0050450171733d44d2049e0585f0 Content-Type: text/plain; charset=UTF-8 I am rather ambivalent, however if we do it we should do it now. I do agree with the following: 1. It would be nice to understand what is a "control" frame, especially if an extension wants to define its own definition of a control frame that should not be fragmented. If we had a single control frame opcode and the first byte defined which control it was (with some number reserved for extensions), this would be much clearer. The other points about scarcity of opcodes or making it lower cost hold some value to me, but frankly not nearly as much as the first. I will make the change unless anyone objects strongly. On Tue, Mar 8, 2011 at 8:13 PM, Greg Wilkins wrote: > Ian, > > What are your thoughts about this as editor? there does not appear to > be any opposed and there is support for Johns original proposal. > It would be good to know soon if you think this will be in -07, as it > affects the server APIs somewhat. > > cheers > > > > > On 4 March 2011 04:25, Bruce Atherton wrote: > > On 02/03/2011 11:13 AM, John Tamplin wrote: > >> > >> My suggestion would be to define a CONTROL opcode, and then for that > >> opcode the first byte of the payload defines which control frame is > >> present. > > > > +1. Simply from a design perspective it makes more sense. Text frame, > binary > > frame, continuation frame, and control frame all feel like the same level > of > > abstraction. Breaking control down into ping, pong, and close seems like > an > > abstraction imbalance. And what do you gain by taking this deep-dive on > the > > control frames? Saving a single byte from a frame that is already tiny? > > > > Plus there are the other benefits you mention. I just think this makes > > sense. > > > > > > _______________________________________________ > > 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 > --0050450171733d44d2049e0585f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am rather=C2=A0ambivalent, however if we do it we should do it now. I do = agree with the following:

1. It would be nice to underst= and what is a "control" frame, especially if an extension wants t= o define its own definition of a control frame that should not be fragmente= d. If we had a single control frame opcode and the first byte defined which= control it was (with some number reserved for extensions), this would be m= uch clearer.

The other points about scarcity of opcodes or making it= lower cost hold some value to me, but frankly not nearly as much as the fi= rst.

I will make the change unless anyone objects = strongly.=C2=A0

On Tue, Mar 8, 2011 at 8:13 PM, Greg Wilkins= <gregw@webtide.c= om> wrote:
Ian,

What are your thoughts about this as editor? =C2=A0there does not appear to=
be any opposed and there is support for Johns original proposal.
It would be good to know soon if you think this will be in -07, as it
affects the server APIs somewhat.

cheers




On 4 March 2011 04:25, Bruce Atherton <bruce@callenish.com> wrote:
> On 02/03/2011 11:13 AM, John Tamplin wrote:
>>
>> My suggestion would be to define a CONTROL opcode, and then for th= at
>> opcode the first byte of the payload defines which control frame i= s
>> present.
>
> +1. Simply from a design perspective it makes more sense. Text frame, = binary
> frame, continuation frame, and control frame all feel like the same le= vel of
> abstraction. Breaking control down into ping, pong, and close seems li= ke an
> abstraction imbalance. And what do you gain by taking this deep-dive o= n the
> control frames? Saving a single byte from a frame that is already tiny= ?
>
> Plus there are the other benefits you mention. I just think this makes=
> sense.
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--0050450171733d44d2049e0585f0-- From ifette@google.com Tue Mar 8 20:55:17 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4F53A67FD for ; Tue, 8 Mar 2011 20:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.526 X-Spam-Level: X-Spam-Status: No, score=-105.526 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq6c61lP6Xts for ; Tue, 8 Mar 2011 20:55:16 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id EA3B53A6817 for ; Tue, 8 Mar 2011 20:55:15 -0800 (PST) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id p294uUhv014101 for ; Tue, 8 Mar 2011 20:56:31 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299646591; bh=xwXsT/W1dzfoC1XgWXAtG1VhGSs=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=ItlRtsWDq/qhgNZyfqRyYkRei1stB0Wjt1JhIG5TgLmjMEq0jUenn6U0GkuPTURSn G2Oa6IFjsLzmTAEZ2cPjA== Received: from iwn10 (iwn10.prod.google.com [10.241.68.74]) by kpbe11.cbf.corp.google.com with ESMTP id p294uH7V005321 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 8 Mar 2011 20:56:29 -0800 Received: by iwn10 with SMTP id 10so202392iwn.34 for ; Tue, 08 Mar 2011 20:56:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dNdIMefPZYMI8Ko5AdJpYUsErBjweYC0U45QDsMPH90=; b=EwGnsPxBU0FmpJUN97ZXo46amDFrWtzGu7yTyGVVgJ8zwDO4HZ8THlnlTPK8vPDqHV yLYcIokw2zLvtfMA4leQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=YVw+E3dElBWeFZdJV9oFSX0yLJ1nqReOhFRzo7MGno83KQ8ikIkKDkvhVN2DwBMyRa VrbOonh2x0xfLoUlDNqA== MIME-Version: 1.0 Received: by 10.231.146.18 with SMTP id f18mr4462742ibv.185.1299646587697; Tue, 08 Mar 2011 20:56:27 -0800 (PST) Received: by 10.231.34.131 with HTTP; Tue, 8 Mar 2011 20:56:27 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Mar 2011 20:56:27 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Greg Wilkins Content-Type: multipart/alternative; boundary=0016e64afdc6317a2b049e058db0 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Browser plans? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 04:55:17 -0000 --0016e64afdc6317a2b049e058db0 Content-Type: text/plain; charset=UTF-8 We are in the midst of updating Chrome to -06. On Tue, Mar 8, 2011 at 8:14 PM, Greg Wilkins wrote: > Are any browsers planning to come out with -06 support ? > > regards > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --0016e64afdc6317a2b049e058db0 Content-Type: text/html; charset=UTF-8 We are in the midst of updating Chrome to -06.

On Tue, Mar 8, 2011 at 8:14 PM, Greg Wilkins <gregw@intalio.com> wrote:
Are any browsers planning to come out with -06 support ?

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

--0016e64afdc6317a2b049e058db0-- From theturtle32@gmail.com Tue Mar 8 23:27:46 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301EC3A67ED for ; Tue, 8 Mar 2011 23:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4U-8CxQWyATX for ; Tue, 8 Mar 2011 23:27:45 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3DA633A67E1 for ; Tue, 8 Mar 2011 23:27:45 -0800 (PST) Received: by iwl42 with SMTP id 42so328713iwl.31 for ; Tue, 08 Mar 2011 23:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=FnmBIDGK4EwuH1untClv1N1xRf3fhdeba+RBNArxxpI=; b=Gjss74ujI0pDGmsfLJY3+2QqR8rQDXIkzjelilrANuWQegUlgaCH3Pi1qEAygEQ3iF r3XmEnSkMO2jgjzwrzGZMUaKlTYLTF3iXuSisK/9nx1qFD6OzqewWl8KOd6I3Be2pKLW ZQGFH1w0iaFB/ZQ21jzhCLBIYD+i/kJCJzWTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YtWZ6edNC8FqWiVntSvblkPNvJGWd6WnGsZ6bfdU6OBL7eYL1xShbuLFydNv9SEQfZ 4btVXhv7q6rSVEM5bxXMzxiQZ0AcUMT+szBKi9OwCilJ5xnM/gbrvd2iod6ADWmlus0I YguCrsyFuolOPleG8RCaIl5/JQaO100rQXAp0= MIME-Version: 1.0 Received: by 10.231.25.106 with SMTP id y42mr4594589ibb.187.1299655741164; Tue, 08 Mar 2011 23:29:01 -0800 (PST) Received: by 10.231.149.19 with HTTP; Tue, 8 Mar 2011 23:29:01 -0800 (PST) Date: Tue, 8 Mar 2011 23:29:01 -0800 Message-ID: From: Brian To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 07:27:46 -0000 In hope of getting consensus on the idea that only the payload and extension data should be masked and not the framing itself, I took a pass at adjusting sections 4.1 and 4.2 accordingly. It didn't take much, just a few minor tweaks. What do you think? Any chance we could reach a rough consensus on masking only the extension/payload data? 4.1. Overview In the WebSocket protocol, data is transmitted using a sequence of frames. The payload portion of frames sent from the client to the server is always masked to avoid confusing network intermediaries, such as intercepting proxies. The payload portion of frames sent from the server to the client are not masked. The base framing protocol defines a frame type with an opcode, a payload length, and designated locations for extension and application data, which together define the _payload_ data. Certain bits and opcodes are reserved for future expansion of the protocol. As such, In the absence of extensions negotiated during the opening handshake (Section 5), all reserved bits MUST be 0 and reserved opcode values MUST NOT be used. A data frame MAY be transmitted by either the client or the server at any time after handshake completion and before that endpoint has sent a close message (Section 4.5.1). 4.2. Client-to-Server Masking The client MUST mask the payload of all frames sent to the server, including all extension data. The masking-key is contained completely within the payload. The masking-key is a 32-bit value chosen at random by the client. The masking-key MUST be derived from a strong source of entropy, and the masking-key for a given frame MUST NOT make it simple for a server to predict the masking-key for the payload in a subsequent frame. Each masked payload consists of a 32-bit masking-key followed by masked-data: masked-payload = masking-key masked-data masking-key = 4full-octet masked-data = *full-octet full-octet = %x00-FF The masked-data is the clear-text payload "encrypted" using a simple XOR cipher as follows. Octet i of the masked-data is the XOR of octet i of the clear text frame with octet i modulo 4 of the masking-key: j = i MOD 4 masked-octet-i = clear-text-octet-i XOR octet-j-of-masking-key When preparing a masked-payload, the client MUST pick a fresh masking- key uniformly at random from the set of allowed 32-bit values. The unpredictability of the masking-nonce is essential to prevent the author of malicious application data from selecting the bytes that appear on the wire. Brian McKelvey From andy.warmcat.com@googlemail.com Tue Mar 8 23:45:57 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD4F3A685D for ; Tue, 8 Mar 2011 23:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.586 X-Spam-Level: X-Spam-Status: No, score=-4.586 tagged_above=-999 required=5 tests=[AWL=1.013, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REdu7zM6mL0k for ; Tue, 8 Mar 2011 23:45:57 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id BEDDF3A6822 for ; Tue, 8 Mar 2011 23:45:56 -0800 (PST) Received: by wwa36 with SMTP id 36so191444wwa.13 for ; Tue, 08 Mar 2011 23:47:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XApMwh8wCql0p/pmXBgCtRMHIWo/AP4wm2WNDBBL7Ow=; b=mfiJULMi9+MjFq78Rqb5ujl5FKFrZz5cRyqSNu+a7vGwfg2uRffmTgbNNZykGXrp7D wk0u7fkjxSWMKjY1I/YFyZ9CkW5LlqdbrOpBwyXLOPRy7+rrwnT/l+iDEdMfIZhUgpz0 tiOCxKKmGEKI4ZoCTBIRORMgIxqOLTZGuQENY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ZXtPkJL0rbdFK33vScsj3kL3qp56cqGIkU8pGNo70J3VU80D4bKyyqEiEFM4+4rfBA qbA8ylZslyZZIKVKgkeewP75bzuH7vbICegCZmrCnYqiM2+Ppye0FYVD1BLBldi852uY KIiwqAJ3N+fLBmAq8KsRcGWgf6s5NpQjGgexs= Received: by 10.227.174.199 with SMTP id u7mr5444679wbz.75.1299656832245; Tue, 08 Mar 2011 23:47:12 -0800 (PST) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id o6sm1247083wbo.21.2011.03.08.23.47.11 (version=SSLv3 cipher=OTHER); Tue, 08 Mar 2011 23:47:11 -0800 (PST) Sender: Andy Green Message-ID: <4D77307E.8080201@warmcat.com> Date: Wed, 09 Mar 2011 07:47:10 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: Brian References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 07:45:58 -0000 On 03/09/2011 07:29 AM, Somebody in the thread at some point said: > In hope of getting consensus on the idea that only the payload and > extension data should be masked and not the framing itself, I took a > pass at adjusting sections 4.1 and 4.2 accordingly. It didn't take > much, just a few minor tweaks. > > What do you think? Any chance we could reach a rough consensus on > masking only the extension/payload data? +1 from me. It also solves Toni Ruottu's slightly exotic case where he might want to mask his server frames, since he can do that as a legit extension negotiated at handshake-time, stick his mask as first extension data, then and the framing and content structure is identical to masked client frames. I also remind folks that to set the clear length field in Javascript, you have to get the browser to accept to create an object of the requisite length. That extends past 1GB for 4 bytes of ASCII and 256GB for 5 bytes of ASCII starting with a letter. Since the next thing is defined to be the mask in extension data, 3 or 4 bytes of control is all you can realistically hope for. If you can knock over an intermediary with 4 bytes, then it will fall over anyway once every 4G frames that go through it and beyond caring about. -Andy From Yutaka_Takeda@PlayStation.Sony.Com Wed Mar 9 00:15:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F12303A6870 for ; Wed, 9 Mar 2011 00:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.03 X-Spam-Level: X-Spam-Status: No, score=-6.03 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6OUwjKWF3Pg for ; Wed, 9 Mar 2011 00:15:32 -0800 (PST) Received: from paris.playstation.sony.com (nat.playstation.sony.com [69.36.131.254]) by core3.amsl.com (Postfix) with ESMTP id A9EF33A6857 for ; Wed, 9 Mar 2011 00:15:32 -0800 (PST) Received: from constantine.playstation.sony.com ([162.49.67.15]) by paris.playstation.sony.com (Lotus Domino Release 8.5.1FP5) with ESMTP id 2011030900164730-223913 ; Wed, 9 Mar 2011 00:16:47 -0800 In-Reply-To: To: Brian MIME-Version: 1.0 X-KeepSent: 40EDB0D5:2670DA1E-8825784E:002C7BB4; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Yutaka_Takeda@PlayStation.Sony.Com Date: Wed, 9 Mar 2011 00:16:43 -0800 X-MIMETrack: Serialize by Router on SCEA919ML04/SCEA(Release 8.5.1FP3|May 23, 2010) at 03/09/2011 12:16:47 AM, Serialize complete at 03/09/2011 12:16:47 AM, Itemize by SMTP Server on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/09/2011 12:16:47 AM, Serialize by Router on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/09/2011 12:16:49 AM, Serialize complete at 03/09/2011 12:16:49 AM Content-Type: multipart/alternative; boundary="=_alternative 002D7AE98825784E_=" Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 08:15:34 -0000 This is a multipart message in MIME format. --=_alternative 002D7AE98825784E_= Content-Type: text/plain; charset="US-ASCII" > In hope of getting consensus on the idea that only the payload and > extension data should be masked and not the framing itself, I took a > pass at adjusting sections 4.1 and 4.2 accordingly. It didn't take > much, just a few minor tweaks. > > What do you think? Any chance we could reach a rough consensus on > masking only the extension/payload data? +1 from me, if it helps. Also, I agree all of pros/cons decribed in Wiki page someone summarized(thanks!): http://trac.tools.ietf.org/wg/hybi/trac/wiki/MaskingProposals - Yutaka > 4.1. Overview > > In the WebSocket protocol, data is transmitted using a sequence of > frames. The payload portion of frames sent from the client to the > server is always masked to avoid confusing network intermediaries, > such as intercepting proxies. The payload portion of frames sent > from the server to the client are not masked. > > The base framing protocol defines a frame type with an opcode, a > payload length, and designated locations for extension and > application data, which together define the _payload_ data. Certain > bits and opcodes are reserved for future expansion of the protocol. > As such, In the absence of extensions negotiated during the opening > handshake (Section 5), all reserved bits MUST be 0 and reserved > opcode values MUST NOT be used. > > A data frame MAY be transmitted by either the client or the server at > any time after handshake completion and before that endpoint has sent > a close message (Section 4.5.1). > > 4.2. Client-to-Server Masking > > The client MUST mask the payload of all frames sent to the server, > including all extension data. > > The masking-key is contained completely within the payload. > > The masking-key is a 32-bit value chosen at random by the client. > The masking-key MUST be derived from a strong source of entropy, and > the masking-key for a given frame MUST NOT make it simple for a > server to predict the masking-key for the payload in a subsequent > frame. > > Each masked payload consists of a 32-bit masking-key followed by > masked-data: > > > masked-payload = masking-key masked-data > masking-key = 4full-octet > masked-data = *full-octet > full-octet = %x00-FF > > > The masked-data is the clear-text payload "encrypted" using a simple > XOR cipher as follows. > > > Octet i of the masked-data is the XOR of octet i of the clear text > frame with octet i modulo 4 of the masking-key: > j = i MOD 4 > masked-octet-i = clear-text-octet-i XOR octet-j-of-masking-key > > > When preparing a masked-payload, the client MUST pick a fresh masking- > key uniformly at random from the set of allowed 32-bit values. The > unpredictability of the masking-nonce is essential to prevent the > author of malicious application data from selecting the bytes that > appear on the wire. > > > > > Brian McKelvey > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --=_alternative 002D7AE98825784E_= Content-Type: text/html; charset="US-ASCII"

> In hope of getting consensus on the idea that only the payload and
> extension data should be masked and not the framing itself, I took a
> pass at adjusting sections 4.1 and 4.2 accordingly.  It didn't take
> much, just a few minor tweaks.
>
> What do you think?  Any chance we could reach a rough consensus on
> masking only the extension/payload data?

+1 from me, if it helps.


Also, I agree all of pros/cons decribed in Wiki page someone summarized(thanks!):
http://trac.tools.ietf.org/wg/hybi/trac/wiki/MaskingProposals


- Yutaka



> 4.1.  Overview
>
>    In the WebSocket protocol, data is transmitted using a sequence of
>    frames.  The payload portion of frames sent from the client to the
>    server is always masked to avoid confusing network intermediaries,
>    such as intercepting proxies.  The payload portion of frames sent
>    from the server to the client are not masked.
>
>    The base framing protocol defines a frame type with an opcode, a
>    payload length, and designated locations for extension and
>    application data, which together define the _payload_ data.  Certain
>    bits and opcodes are reserved for future expansion of the protocol.
>    As such, In the absence of extensions negotiated during the opening
>    handshake (Section 5), all reserved bits MUST be 0 and reserved
>    opcode values MUST NOT be used.
>
>    A data frame MAY be transmitted by either the client or the server at
>    any time after handshake completion and before that endpoint has sent
>    a close message (Section 4.5.1).
>
> 4.2.  Client-to-Server Masking
>
>    The client MUST mask the payload of all frames sent to the server,
>    including all extension data.
>
>    The masking-key is contained completely within the payload.
>
>    The masking-key is a 32-bit value chosen at random by the client.
>    The masking-key MUST be derived from a strong source of entropy, and
>    the masking-key for a given frame MUST NOT make it simple for a
>    server to predict the masking-key for the payload in a subsequent
>    frame.
>
>    Each masked payload consists of a 32-bit masking-key followed by
>    masked-data:
>
>
>      masked-payload  = masking-key masked-data
>      masking-key     = 4full-octet
>      masked-data     = *full-octet
>      full-octet      = %x00-FF
>
>
>    The masked-data is the clear-text payload "encrypted" using a simple
>    XOR cipher as follows.
>
>
>    Octet i of the masked-data is the XOR of octet i of the clear text
>    frame with octet i modulo 4 of the masking-key:
>      j              = i MOD 4
>      masked-octet-i = clear-text-octet-i XOR octet-j-of-masking-key
>
>
>    When preparing a masked-payload, the client MUST pick a fresh masking-
>    key uniformly at random from the set of allowed 32-bit values.  The
>    unpredictability of the masking-nonce is essential to prevent the
>    author of malicious application data from selecting the bytes that
>    appear on the wire.
>
>
>
>
> Brian McKelvey
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
 --=_alternative 002D7AE98825784E_=-- From ifette@google.com Wed Mar 9 00:26:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F2E3A68AA for ; Wed, 9 Mar 2011 00:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.54 X-Spam-Level: X-Spam-Status: No, score=-105.54 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXhZk8ZA7ynD for ; Wed, 9 Mar 2011 00:26:25 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 004CD3A687D for ; Wed, 9 Mar 2011 00:26:24 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p298RdYH017717 for ; Wed, 9 Mar 2011 00:27:39 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299659260; bh=vjAM8YKt/fJPhWZbY6qJDVn1uRI=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=lY+3y/vUly7wO/QsaaJFeTbKaT7bC0Z58VSVQXChhytkoSJQdlkOSOMDMoAyHcs2/ HUz4a0OaJWaxsB9PGESfg== Received: from iwn9 (iwn9.prod.google.com [10.241.68.73]) by wpaz21.hot.corp.google.com with ESMTP id p298RGrU028277 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 9 Mar 2011 00:27:38 -0800 Received: by iwn9 with SMTP id 9so347863iwn.23 for ; Wed, 09 Mar 2011 00:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=w2vit4A9GZl+DHvSt9yrCNZsW582JRsHlzHq5Zm4H2A=; b=jXoAeWmvLsUYlTbLFPFmtbRC7ITuJAja/6ZuIdc44W20GXPuuqHwNdXJQoGQ76agkF adOCK1P3S/CboWmAwC1Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=AV6liKkOjTlbLwfuhbghAOh3cqC27jj6vvBzbpjI41Iy1PuRVajSw7bAi9EZJVrsUs werHUYBlvdOfTK1OxoYg== MIME-Version: 1.0 Received: by 10.43.54.71 with SMTP id vt7mr7878789icb.225.1299659256565; Wed, 09 Mar 2011 00:27:36 -0800 (PST) Received: by 10.231.34.131 with HTTP; Wed, 9 Mar 2011 00:27:36 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Mar 2011 00:27:36 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Brian Content-Type: multipart/alternative; boundary=bcaec51d2a7c510e13049e088093 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 08:26:27 -0000 --bcaec51d2a7c510e13049e088093 Content-Type: text/plain; charset=UTF-8 Can someone please explain to me why this matters? Given that we went with a 32-bit mask included in the frame, and it's just xor, I'm really not sympathetic to arguments about "it's hard to unmask" etc. The only thing that I've heard that resonates at all is that you have to know which direction the connection is going, e.g. which is the client and which is the server, that said it seems like any proxy doing anything interesting would probably already know this? -Ian On Tue, Mar 8, 2011 at 11:29 PM, Brian wrote: > In hope of getting consensus on the idea that only the payload and > extension data should be masked and not the framing itself, I took a > pass at adjusting sections 4.1 and 4.2 accordingly. It didn't take > much, just a few minor tweaks. > > What do you think? Any chance we could reach a rough consensus on > masking only the extension/payload data? > > > > 4.1. Overview > > In the WebSocket protocol, data is transmitted using a sequence of > frames. The payload portion of frames sent from the client to the > server is always masked to avoid confusing network intermediaries, > such as intercepting proxies. The payload portion of frames sent > from the server to the client are not masked. > > The base framing protocol defines a frame type with an opcode, a > payload length, and designated locations for extension and > application data, which together define the _payload_ data. Certain > bits and opcodes are reserved for future expansion of the protocol. > As such, In the absence of extensions negotiated during the opening > handshake (Section 5), all reserved bits MUST be 0 and reserved > opcode values MUST NOT be used. > > A data frame MAY be transmitted by either the client or the server at > any time after handshake completion and before that endpoint has sent > a close message (Section 4.5.1). > > 4.2. Client-to-Server Masking > > The client MUST mask the payload of all frames sent to the server, > including all extension data. > > The masking-key is contained completely within the payload. > > The masking-key is a 32-bit value chosen at random by the client. > The masking-key MUST be derived from a strong source of entropy, and > the masking-key for a given frame MUST NOT make it simple for a > server to predict the masking-key for the payload in a subsequent > frame. > > Each masked payload consists of a 32-bit masking-key followed by > masked-data: > > > masked-payload = masking-key masked-data > masking-key = 4full-octet > masked-data = *full-octet > full-octet = %x00-FF > > > The masked-data is the clear-text payload "encrypted" using a simple > XOR cipher as follows. > > > Octet i of the masked-data is the XOR of octet i of the clear text > frame with octet i modulo 4 of the masking-key: > j = i MOD 4 > masked-octet-i = clear-text-octet-i XOR octet-j-of-masking-key > > > When preparing a masked-payload, the client MUST pick a fresh masking- > key uniformly at random from the set of allowed 32-bit values. The > unpredictability of the masking-nonce is essential to prevent the > author of malicious application data from selecting the bytes that > appear on the wire. > > > > > Brian McKelvey > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --bcaec51d2a7c510e13049e088093 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Can someone please explain to me why this matters? Given that we went with = a 32-bit mask included in the frame, and it's just xor, I'm really = not sympathetic to arguments about "it's hard to unmask" etc.= The only thing that I've heard that resonates at all is that you have = to know which direction the connection is going, e.g. which is the client a= nd which is the server, that said it seems like any proxy doing anything in= teresting would probably already know this?

-Ian

On Tue, Mar 8, 2011 a= t 11:29 PM, Brian <theturtle32@gmail.com> wrote:
In hope of getting consensus on the idea that only the payload and
extension data should be masked and not the framing itself, I took a
pass at adjusting sections 4.1 and 4.2 accordingly. =C2=A0It didn't tak= e
much, just a few minor tweaks.

What do you think? =C2=A0Any chance we could reach a rough consensus on
masking only the extension/payload data?



4.1. =C2=A0Overview

=C2=A0 In the WebSocket protocol, data is transmitted using a sequence of<= br> =C2=A0 frames. =C2=A0The payload portion of frames sent from the client to= the
=C2=A0 server is always masked to avoid confusing network intermediaries,<= br> =C2=A0 such as intercepting proxies. =C2=A0The payload portion of frames s= ent
=C2=A0 from the server to the client are not masked.

=C2=A0 The base framing protocol defines a frame type with an opcode, a =C2=A0 payload length, and designated locations for extension and
=C2=A0 application data, which together define the _payload_ data. =C2=A0C= ertain
=C2=A0 bits and opcodes are reserved for future expansion of the protocol.=
=C2=A0 As such, In the absence of extensions negotiated during the opening=
=C2=A0 handshake (Section 5), all reserved bits MUST be 0 and reserved
=C2=A0 opcode values MUST NOT be used.

=C2=A0 A data frame MAY be transmitted by either the client or the server = at
=C2=A0 any time after handshake completion and before that endpoint has se= nt
=C2=A0 a close message (Section 4.5.1).

4.2. =C2=A0Client-to-Server Masking

=C2=A0 The client MUST mask the payload of all frames sent to the server,<= br> =C2=A0 including all extension data.

=C2=A0 The masking-key is contained completely within the payload.

=C2=A0 The masking-key is a 32-bit value chosen at random by the client. =C2=A0 The masking-key MUST be derived from a strong source of entropy, an= d
=C2=A0 the masking-key for a given frame MUST NOT make it simple for a
=C2=A0 server to predict the masking-key for the payload in a subsequent =C2=A0 frame.

=C2=A0 Each masked payload consists of a 32-bit masking-key followed by =C2=A0 masked-data:


=C2=A0 =C2=A0 masked-payload =C2=A0=3D masking-key masked-data
=C2=A0 =C2=A0 masking-key =C2=A0 =C2=A0 =3D 4full-octet
=C2=A0 =C2=A0 masked-data =C2=A0 =C2=A0 =3D *full-octet
=C2=A0 =C2=A0 full-octet =C2=A0 =C2=A0 =C2=A0=3D %x00-FF


=C2=A0 The masked-data is the clear-text payload "encrypted" usi= ng a simple
=C2=A0 XOR cipher as follows.


=C2=A0 Octet i of the masked-data is the XOR of octet i of the clear text<= br> =C2=A0 frame with octet i modulo 4 of the masking-key:
=C2=A0 =C2=A0 j =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D i MOD = 4
=C2=A0 =C2=A0 masked-octet-i =3D clear-text-octet-i XOR octet-j-of-masking= -key


=C2=A0 When preparing a masked-payload, the client MUST pick a fresh maski= ng-
=C2=A0 key uniformly at random from the set of allowed 32-bit values. =C2= =A0The
=C2=A0 unpredictability of the masking-nonce is essential to prevent the =C2=A0 author of malicious application data from selecting the bytes that<= br> =C2=A0 appear on the wire.




Brian McKelvey
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--bcaec51d2a7c510e13049e088093-- From andy.warmcat.com@googlemail.com Wed Mar 9 00:44:12 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1E13A68B0 for ; Wed, 9 Mar 2011 00:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oK4SrQkmV-y0 for ; Wed, 9 Mar 2011 00:44:11 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DA7DF3A68AA for ; Wed, 9 Mar 2011 00:44:10 -0800 (PST) Received: by wwa36 with SMTP id 36so221274wwa.13 for ; Wed, 09 Mar 2011 00:45:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dqtkrCS0QRhMqCnxEH3hvyVOF6mIo+xg3S9kM3b0CGU=; b=cz+O0y6yAkeeH45Q87952DIGyM+1lrNCPzLWyvIsqG+RupOX7yZ5Z7izLiACyJgJmr IuU51yzV3pOwsEUlFyi5QDCfpQXrjj6RSRzwF+nn54ZoCBZvFsuXx0qwDOfA9+frmeCV CM5QVaPk9WZgx82UCGwxMx+wQ6znrvEThmIYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=QkMhGvSR4SrtAMzPm2L7ZIxlcLMmuy1co1PGuT5F3K8kWWrG1vhApVbCeeuez9/Z+m a4dFYMGYu/0zfqub30Jx+HWIEuohIqYfA4IrcpR4RzV80tQBXH7C52Sse99KeESSY167 Bsv98hU7YttFGONCZvfFmQVg8UK3SlxbMwvbk= Received: by 10.227.201.130 with SMTP id fa2mr5410723wbb.172.1299660326400; Wed, 09 Mar 2011 00:45:26 -0800 (PST) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id u9sm1284126wbg.0.2011.03.09.00.45.24 (version=SSLv3 cipher=OTHER); Wed, 09 Mar 2011 00:45:25 -0800 (PST) Sender: Andy Green Message-ID: <4D773E24.7080104@warmcat.com> Date: Wed, 09 Mar 2011 08:45:24 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: ifette@google.com References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 08:44:12 -0000 On 03/09/2011 08:27 AM, Somebody in the thread at some point said: Hi - > Can someone please explain to me why this matters? Given that we went > with a 32-bit mask included in the frame, and it's just xor, I'm really It's not driven by complaints about the masking complexity. > not sympathetic to arguments about "it's hard to unmask" etc. The only > thing that I've heard that resonates at all is that you have to know > which direction the connection is going, e.g. which is the client and > which is the server, that said it seems like any proxy doing anything > interesting would probably already know this? Because it's a streamed protocol, one problem it creates is a snooper trying to perform frame sync on stuff coming out of a client can find a pathological situation as it is, it's literally a randomized stream with no structure at all that may not have any framing relationship to packet boundaries. It's four random bytes then everything xor'd with random without let-up, there's nothing to grab hold of once it has started. If the framing is left standing proud of the mask action, there is at least always framing structure in the stream to sync on. Also although I am grateful for the choice you made of simply 4-byte mask compared to AES and other castles in the air, actually sticking a fixed 4-bytes on the front in one direction is kind of a hack protocol-wise. If the framing is definitely the boss in this protocol, and not subordinate to the masking, then it will be possible to negotiate different masking schemes at handshake-time if that becomes desirable without changing intermediaries that don't care about payload but must watch the streams for control packets or whatever: the intermediaries can just obey framing rules even with no masking negotiated or ROT13 or whatever negotiated that they don't understand or care about, but now won't break on. As mentioned one specific case of wanting to do the above is Toni Ruottu's where the browser emits server frames. He can solve his quandry with just an extension then, changing masking rules without upsetting the framing rules and so allowing things that don't understand to not break. -Andy From Yutaka_Takeda@PlayStation.Sony.Com Wed Mar 9 01:53:49 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECAC83A67A7 for ; Wed, 9 Mar 2011 01:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.038 X-Spam-Level: X-Spam-Status: No, score=-6.038 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhsQ-Hty62PT for ; Wed, 9 Mar 2011 01:53:48 -0800 (PST) Received: from paris.playstation.sony.com (nat.playstation.sony.com [69.36.131.254]) by core3.amsl.com (Postfix) with ESMTP id AA3D83A67F1 for ; Wed, 9 Mar 2011 01:53:48 -0800 (PST) Received: from constantine.playstation.sony.com ([162.49.67.15]) by paris.playstation.sony.com (Lotus Domino Release 8.5.1FP5) with ESMTP id 2011030901550400-225276 ; Wed, 9 Mar 2011 01:55:04 -0800 In-Reply-To: To: hybi@ietf.org MIME-Version: 1.0 X-KeepSent: 27A0495D:2C32912B-8825784E:00342DCE; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Yutaka_Takeda@PlayStation.Sony.Com Date: Wed, 9 Mar 2011 01:55:01 -0800 X-MIMETrack: Serialize by Router on SCEA919ML04/SCEA(Release 8.5.1FP3|May 23, 2010) at 03/09/2011 01:55:03 AM, Serialize complete at 03/09/2011 01:55:03 AM, Itemize by SMTP Server on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/09/2011 01:55:04 AM, Serialize by Router on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/09/2011 01:55:05 AM, Serialize complete at 03/09/2011 01:55:05 AM Content-Type: multipart/alternative; boundary="=_alternative 00367A838825784E_=" Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 09:53:50 -0000 This is a multipart message in MIME format. --=_alternative 00367A838825784E_= Content-Type: text/plain; charset="US-ASCII" This thread, too, I am wondering if this has reached a consensus at this point. At least, Greg, Brian and myself agreed to have only payload deflated. This aligns with the reasons for choosing masking in frames, too. Also, it resolves the original issue Takeshi pointed out with regards to presence of trailing bytes after Close frame as in the subject which would cause RST in normal termination. - Yutaka hybi-bounces@ietf.org wrote on 02/28/2011 11:37:17 PM: > > Hi John, > > hybi-bounces@ietf.org wrote on 02/28/2011 06:32:03 AM: > > > [BTW - here is the thread where I first posted results of an > > experiment - http://www.ietf.org/mail-archive/web/hybi/current/msg01810.html > > ] > > > > On Mon, Feb 28, 2011 at 4:52 AM, Greg Wilkins wrote: > > > I'm +1 for compression within the frame. > > > > > > If we compress the framing, then intermediaries will have to > > > decompress in order to see framing and to know when to forward etc. > > > It also has significant debug issues as it makes it much harder to > > > decode a partial frame capture. > > > > > > I understand the argument that compression will not be as good, but I > > > think some compromise is necessary. > > > > The framing is pretty small and it is hard to imagine much redundancy > > from the header (the opcode and reserved bits will be constant, but > > then you will interfere with the compression by all the constantly > > changing lengths), so I think little is lost by compressing only the > > payload. > > Just to be clear, the compression does not have to be per payload of > a data frame, but can be entire stream of messages application passes in. > At the end of the message, though, F_SYNC_FLUSH is necessary to prevent > receiver from waiting for the last compressed data to arrive from sender, > but we should be aware that the compressor still maintains 32kB(or whatever > it is configured for) of reference range in its context. > > > > > However, it does mean the implementation is more complicated, and I > > It is actually very simple, in python for example: > > > zlibObj = zlib.compressobj() > > def send(in_data): > buf = zlibObj.compress(in_data) > buf += zlibObj.flush(zilib.Z_SYNC_FLUSH) > : > (construct frames/fragments and put into a queue) > > Note: the 'zlibObj' has the same lifetime as that of WebSocket. > > > > don't believe this would be feasible using the stock inflate/deflate > > in Java for example. I would not agree to just compressing each > > frame's payload independently -- my earlier experiments show this will > > frequently increase the size of the data and result in only modest > > savings compared to maintaining compression state over the life of the > > connection (while we are discussing it, > > Again, lifetime of the compression state/context can be the same. It > just needs, Z_SYNC_FLUSH operation at the end of the 'WS-frame' to avoid > unnecessary delay. Even compression was done for whole stream, we still > need Z_SYNC_FLUSH per frame basis with the exact same reason - we cannot > delay the frame! (Unless we introduce nagle's algorithm like protocol > just for slightly better compression ratio, which I think would not be > feasible.) This, at least to me, looks more complicated. > > I am aware that, if application passes in is very small message > frequently, (Z_SYNC_FLUSH has to be done frequently), resulting > compression ratio would not be that great. However, since we can not > delay each frame, we need the Z_SYNC_FLUSH anyways. Therefore, there's > no benefit in having compression layer under the framing layer. > > As I mentioned earlier, the compression state can be shared between > text and binary messages since they are not interleaved (even fragmented), > though it may be better to have dedicated compression state if we can > afford memory. Either way, we need to define the spec in the document. > > > - Yutaka > > > > we should talk about the > > parameters to use for deflate to minimize memory requirements on the > > server -- experiments done for compression in SPDY [mentioned in the > > linked thread] show you can get most of the benefit with more modest > > memory requirements using lower parameters). > > > > It also means we have to agree on the details of how it should be > > specified, which is why the super-simple deflate-stream was added to > > the standard instead of trying to get agreement on something better. > > > > -- > > John A. Tamplin > > Software Engineer (GWT), Google > > _______________________________________________ > > 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 --=_alternative 00367A838825784E_= Content-Type: text/html; charset="US-ASCII"
This thread, too, I am wondering if this has reached a consensus at this point. At least,
Greg, Brian  and myself agreed to have only payload deflated. This aligns with the
reasons for choosing masking in frames, too. Also, it resolves the original issue Takeshi
pointed out with regards to presence of trailing bytes after Close frame as in the subject
which would cause RST in normal termination.


- Yutaka


hybi-bounces@ietf.org wrote on 02/28/2011 11:37:17 PM:

>
> Hi John,
>
> hybi-bounces@ietf.org wrote on 02/28/2011 06:32:03 AM:
>
> > [BTW - here is the thread where I first posted results of an
> > experiment - http://www.ietf.org/mail-archive/web/hybi/current/msg01810.html
> > ]
> >
> > On Mon, Feb 28, 2011 at 4:52 AM, Greg Wilkins <gregw@webtide.com> wrote:
> > > I'm +1 for compression within the frame.
> > >
> > > If we compress the framing, then intermediaries will have to
> > > decompress in order to see framing and to know when to forward etc.
> > > It also has significant debug issues as it makes it much harder to
> > > decode a partial frame capture.
> > >
> > > I understand the argument that compression will not be as good, but I
> > > think some compromise is necessary.
> >
> > The framing is pretty small and it is hard to imagine much redundancy
> > from the header (the opcode and reserved bits will be constant, but
> > then you will interfere with the compression by all the constantly
> > changing lengths), so I think little is lost by compressing only the
> > payload.
>
> Just to be clear, the compression does not have to be per payload of
> a data frame, but can be entire stream of messages application passes in.
> At the end of the message, though, F_SYNC_FLUSH is necessary to prevent
> receiver from waiting for the last compressed data to arrive from sender,
> but we should be aware that the compressor still maintains 32kB(or whatever
> it is configured for) of reference range in its context.
>
> >
> > However, it does mean the implementation is more complicated, and I
>
> It is actually very simple, in python for example:
>
>
>         zlibObj = zlib.compressobj()
>
>         def send(in_data):
>                    buf = zlibObj.compress(in_data)
>                    buf += zlibObj.flush(zilib.Z_SYNC_FLUSH)
>                         :
>                 (construct frames/fragments and put into a queue)
>
> Note: the 'zlibObj' has the same lifetime as that of WebSocket.
>
>
> > don't believe this would be feasible using the stock inflate/deflate
> > in Java for example.  I would not agree to just compressing each
> > frame's payload independently -- my earlier experiments show this will
> > frequently increase the size of the data and result in only modest
> > savings compared to maintaining compression state over the life of the
> > connection (while we are discussing it,
>
> Again, lifetime of the compression state/context can be the same. It
> just needs, Z_SYNC_FLUSH operation at the end of the 'WS-frame' to avoid
> unnecessary delay. Even compression was done for whole stream, we still
> need Z_SYNC_FLUSH per frame basis with the exact same reason - we cannot
> delay the frame! (Unless we introduce nagle's algorithm like protocol
> just for slightly better compression ratio, which I think would not be
> feasible.) This, at least to me, looks more complicated.
>
> I am aware that, if application passes in is very small message
> frequently, (Z_SYNC_FLUSH has to be done frequently), resulting
> compression ratio would not be that great. However, since we can not
> delay each frame, we need the Z_SYNC_FLUSH anyways. Therefore, there's
> no benefit in having compression layer under the framing layer.
>
> As I mentioned earlier, the compression state can be shared between
> text and binary messages since they are not interleaved (even fragmented),
> though it may be better to have dedicated compression state if we can
> afford memory. Either way, we need to define the spec in the document.
>
>
> - Yutaka
>
>
> > we should talk about the
> > parameters to use for deflate to minimize memory requirements on the
> > server -- experiments done for compression in SPDY [mentioned in the
> > linked thread] show you can get most of the benefit with more modest
> > memory requirements using lower parameters).
> >
> > It also means we have to agree on the details of how it should be
> > specified, which is why the super-simple deflate-stream was added to
> > the standard instead of trying to get agreement on something better.
> >
> > --
> > John A. Tamplin
> > Software Engineer (GWT), Google
> > _______________________________________________
> > 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
 --=_alternative 00367A838825784E_=-- From salvatore.loreto@ericsson.com Wed Mar 9 02:16:03 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5209C3A68E3 for ; Wed, 9 Mar 2011 02:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZWAIUIVvTtY for ; Wed, 9 Mar 2011 02:16:02 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7DE9B3A68F0 for ; Wed, 9 Mar 2011 02:16:01 -0800 (PST) X-AuditID: c1b4fb39-b7c6dae0000023f2-11-4d7753ac22d2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4E.3C.09202.CA3577D4; Wed, 9 Mar 2011 11:17:16 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Wed, 9 Mar 2011 11:17:16 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4A0D1263A for ; Wed, 9 Mar 2011 12:17:16 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 109FE509D6 for ; Wed, 9 Mar 2011 12:17:16 +0200 (EET) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BCDD4509BD for ; Wed, 9 Mar 2011 12:17:15 +0200 (EET) Message-ID: <4D7753AB.8000205@ericsson.com> Date: Wed, 9 Mar 2011 12:17:15 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: hybi@ietf.org References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000407010001050308080902" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [hybi] change in 07: a single Control opcode (was Re: a single CONTROL opcode for all control frames (was Re: Hello frames?)) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 10:16:03 -0000 --------------000407010001050308080902 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit (as co-chair I want to bring your attention to this) Hi there, the following changes (proposed by John Tamplin) in 07: /to define a CONTROL opcode, and then for that opcode the first byte of the payload defines which control frame is present / has been discussed during the last couple of weeks: (see the thread http://www.ietf.org/mail-archive/web/hybi/current/msg06726.html ) the proposal has gather some consensus and so 07 will include this change unless anyone object strongly! cheers /Sal -- Salvatore Loreto www.sloreto.com On 3/9/11 6:54 AM, Ian Fette (イアンフェッティ) wrote: > I am rather ambivalent, however if we do it we should do it now. I do > agree with the following: > > 1. It would be nice to understand what is a "control" frame, > especially if an extension wants to define its own definition of a > control frame that should not be fragmented. If we had a single > control frame opcode and the first byte defined which control it was > (with some number reserved for extensions), this would be much clearer. > > The other points about scarcity of opcodes or making it lower cost > hold some value to me, but frankly not nearly as much as the first. > > I will make the change unless anyone objects strongly. > > On Tue, Mar 8, 2011 at 8:13 PM, Greg Wilkins > wrote: > > Ian, > > What are your thoughts about this as editor? there does not appear to > be any opposed and there is support for Johns original proposal. > It would be good to know soon if you think this will be in -07, as it > affects the server APIs somewhat. > > cheers > > > > > On 4 March 2011 04:25, Bruce Atherton > wrote: > > On 02/03/2011 11:13 AM, John Tamplin wrote: > >> > >> My suggestion would be to define a CONTROL opcode, and then for > that > >> opcode the first byte of the payload defines which control frame is > >> present. > > > > +1. Simply from a design perspective it makes more sense. Text > frame, binary > > frame, continuation frame, and control frame all feel like the > same level of > > abstraction. Breaking control down into ping, pong, and close > seems like an > > abstraction imbalance. And what do you gain by taking this > deep-dive on the > > control frames? Saving a single byte from a frame that is > already tiny? > > > > Plus there are the other benefits you mention. I just think this > makes > > sense. > > > > > > _______________________________________________ > > 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 > > --------------000407010001050308080902 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit (as co-chair I want to bring your attention to this)


Hi there,


the following changes (proposed by John Tamplin) in 07:

to define a CONTROL opcode, and then for that opcode the first byte
of the payload defines which control frame is present

has been discussed during the last couple of weeks:
(see the thread http://www.ietf.org/mail-archive/web/hybi/current/msg06726.html )

the proposal has gather some consensus and so 07 will include this change unless anyone object strongly!

cheers
/Sal


-- 
Salvatore Loreto
www.sloreto.com


On 3/9/11 6:54 AM, Ian Fette (イアンフェッティ) wrote:
I am rather ambivalent, however if we do it we should do it now. I do agree with the following:

1. It would be nice to understand what is a "control" frame, especially if an extension wants to define its own definition of a control frame that should not be fragmented. If we had a single control frame opcode and the first byte defined which control it was (with some number reserved for extensions), this would be much clearer.

The other points about scarcity of opcodes or making it lower cost hold some value to me, but frankly not nearly as much as the first.

I will make the change unless anyone objects strongly. 

On Tue, Mar 8, 2011 at 8:13 PM, Greg Wilkins <gregw@webtide.com> wrote:
Ian,

What are your thoughts about this as editor?  there does not appear to
be any opposed and there is support for Johns original proposal.
It would be good to know soon if you think this will be in -07, as it
affects the server APIs somewhat.

cheers




On 4 March 2011 04:25, Bruce Atherton <bruce@callenish.com> wrote:
> On 02/03/2011 11:13 AM, John Tamplin wrote:
>>
>> My suggestion would be to define a CONTROL opcode, and then for that
>> opcode the first byte of the payload defines which control frame is
>> present.
>
> +1. Simply from a design perspective it makes more sense. Text frame, binary
> frame, continuation frame, and control frame all feel like the same level of
> abstraction. Breaking control down into ping, pong, and close seems like an
> abstraction imbalance. And what do you gain by taking this deep-dive on the
> control frames? Saving a single byte from a frame that is already tiny?
>
> Plus there are the other benefits you mention. I just think this makes
> sense.
>
>
> _______________________________________________
> 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



--------------000407010001050308080902-- From andy.warmcat.com@googlemail.com Wed Mar 9 02:57:38 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 816873A6919 for ; Wed, 9 Mar 2011 02:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4nGQ0tDYhfa for ; Wed, 9 Mar 2011 02:57:37 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 2B5D13A68FE for ; Wed, 9 Mar 2011 02:57:37 -0800 (PST) Received: by wyb42 with SMTP id 42so365600wyb.31 for ; Wed, 09 Mar 2011 02:58:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SEhgc5p8iKmaP687hke5mAuNJPDSoIlpaedRfewQHMw=; b=TQ4otg+RR+qKoHK4R5bzNB+YcRWyOawnFMwi3RmVLpgF9QssMc8iTPM9H6IYkSizVc 2FI5EbGt1wsoPZuHuUV8fBJfgNHL3ibw83hY5IEDIFb0LDBh4K9dLomeuCi7ux8ahF4D yuIH6J/p10ETDuHb1D4MpXHxIvx6otDGrDCkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=IMBxZVctzlZJuI2xsbwvlZ9uWAGOs6hMdYrauybusQoEWmIl0+tkStDS9fTFJnD536 T3Z71S/9+eg+H/iGKK7e3r7neJuVO4J/10YOP+jDXXHnRYE65L9Eiwi8LWWC8ESVk6BJ yKX+IY9bS0Fy/0vfPUPLiprgOgnzH2C0QeRqI= Received: by 10.227.7.18 with SMTP id b18mr2059180wbb.103.1299668332620; Wed, 09 Mar 2011 02:58:52 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id bd8sm1365967wbb.19.2011.03.09.02.58.50 (version=SSLv3 cipher=OTHER); Wed, 09 Mar 2011 02:58:51 -0800 (PST) Sender: Andy Green Message-ID: <4D775D69.8010808@warmcat.com> Date: Wed, 09 Mar 2011 10:58:49 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: Yutaka_Takeda@PlayStation.Sony.Com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 10:57:38 -0000 On 03/09/2011 09:55 AM, Somebody in the thread at some point said: > > This thread, too, I am wondering if this has reached a consensus at this > point. At least, > Greg, Brian and myself agreed to have only payload deflated. This aligns > with the I'd be a bit happier with payload-only compression but I don't really mind. It's a little bit less deadly than masking-outside-framing because you can at least turn off negotiation of compression inside the standard OK if you want to debug it. > reasons for choosing masking in frames, too. Also, it resolves the > original issue Takeshi > pointed out with regards to presence of trailing bytes after Close frame > as in the subject > which would cause RST in normal termination. Having implemented this now, I don't see the problem using Z_PARTIAL_FLUSH as the standard seems to recommend normally, and then Z_FULL_FLUSH when sending the close packet, and disabling any further packet issue on that connection. So I don't think Takeshi's issue is more than an implementation problem, I'd welcome being educated if I missed any point. -Andy From gregw@intalio.com Wed Mar 9 03:03:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F16B3A68FE for ; Wed, 9 Mar 2011 03:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9IJf-mP0tBh for ; Wed, 9 Mar 2011 03:03:38 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 525B13A681A for ; Wed, 9 Mar 2011 03:03:38 -0800 (PST) Received: by vws6 with SMTP id 6so430637vws.31 for ; Wed, 09 Mar 2011 03:04:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.98.169 with SMTP id ej9mr3739536vdb.223.1299668617959; Wed, 09 Mar 2011 03:03:37 -0800 (PST) Sender: gregw@intalio.com Received: by 10.52.169.39 with HTTP; Wed, 9 Mar 2011 03:03:37 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Mar 2011 22:03:37 +1100 X-Google-Sender-Auth: T1g5LixXVC-Pw8lXeKiv1uvcXt4 Message-ID: From: Greg Wilkins To: ifette@google.com Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 11:03:39 -0000 I'm +1 on the proposal. 2011/3/9 Ian Fette ($B%$%"%s%U%'%C%F%#(B) : > Can someone please explain to me why this matters? modified from the earlier thread on this: Masked Frames PROS: + all bytes other than the key are masked. This prevents an attacker from using frame fields like the length to send "clear text" Masked Frame CONS: - Masking is not independent of framing - poor layered protocol design. ie this is the same reason that gzip in HTTP does not change the framing of HTTP messages. - all WS handling that needs to be aware of frame boundaries will need to implement masking. This will mean that more infrastructure will have masking hard coded into it, thus it will soon become very difficult, if not impossible to change framing as it will be baked into WS aware intermediaries. - Intermediaries that do not care about content will still need to unmask and remask the frames. - the parser/generator code for WS becomes more complex and asymmetric because it must implement masking for some WS streams but not for others. - unmasking cannot be done as single optimised pass over the data, but must be done on-the-fly in the parsing code. - the options for masking algorithms is limited. For example session based keys could not be used in a MUX environment as the session key would need to be known to access the extension data to know the stream ID, so the session ID could be known so you can't know the session key. While session based masking may not be desirable for other reasons, this limitation indicates a fundamental limitation of the masked frame approach. Mask in Frame PROS: + Masking is independent of framing. Good layered protocol design. + Intermediaries that do not process the payload will not need to implement masking. This saves CPU, memory and also will make it easier to change and/or remove masking in future. + WS parsing code is simple and symmetric. + session based masking algorithms can be used if desired + Can utilise the extension data space to carry the key - thus testing the implementation of the parsing of extension data length and preventing implementations assuming this will be zero. Mask in Frame CONS: - The frame op-code, flags and length are sent in the clear. Of these, an attacker has reasonable control over the length field, so could conceivably send 8 characters including "GET\n" as the length (although this would be very difficult to do via the current javascript API. There are also simple heuristic defences for this, such as fragmenting any frame that has a length that is all ascii and has a CR) In summary, mask in frame is far more flexible, low cost and demonstrable better design, at cost of exposing a very very unlikely subcase of an already very very unlikely vulnerability to an as of yet undiscovered threat, of which an exploitable variation is already in the wild using non ws clients. From salvatore.loreto@ericsson.com Wed Mar 9 03:36:02 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1365E3A6842 for ; Wed, 9 Mar 2011 03:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zq+scN43pNSh for ; Wed, 9 Mar 2011 03:36:00 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5FC8E3A691D for ; Wed, 9 Mar 2011 03:36:00 -0800 (PST) X-AuditID: c1b4fb3d-b7bbbae000005311-c9-4d77666b1f66 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8D.C4.21265.B66677D4; Wed, 9 Mar 2011 12:37:15 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Wed, 9 Mar 2011 12:37:14 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 64A4524F7 for ; Wed, 9 Mar 2011 13:37:14 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 251AE508DA for ; Wed, 9 Mar 2011 13:37:14 +0200 (EET) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D1E5150435 for ; Wed, 9 Mar 2011 13:37:13 +0200 (EET) Message-ID: <4D776669.20300@ericsson.com> Date: Wed, 9 Mar 2011 13:37:13 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary="------------030303080906070800040500" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [hybi] Fwd: New Version Notification for draft-thomson-hybi-http-timeout-00 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 11:36:02 -0000 --------------030303080906070800040500 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit (as individual) Martin, Greg and I have submitted the following draft: http://tools.ietf.org/id/draft-thomson-hybi-http-timeout-00.txt The draft only defines HTTP headers that can be (re)used for discovery idle time to use in both LongPolling/Comet and WebSocket connection lifetime management (keep alive process). Note, the draft does not discuss the actual WebSocket keep alive process; and this thread is only to discuss the mechanism for discovery idle time. Comments and opinions on the draft are very welcome and appreciate. cheers /Sal -- Salvatore Loreto www.sloreto.com -------- Original Message -------- Subject: New Version Notification for draft-thomson-hybi-http-timeout-00 Date: Mon, 7 Mar 2011 00:09:52 +0100 From: IETF I-D Submission Tool To: martin.thomson@andrew.com CC: Salvatore Loreto , "gregw@intalio.com" A new version of I-D, draft-thomson-hybi-http-timeout-00.txt has been successfully submitted by Martin Thomson and posted to the IETF repository. Filename: draft-thomson-hybi-http-timeout Revision: 00 Title: Hypertext Transfer Protocol (HTTP) Timeouts Creation_date: 2011-03-07 WG ID: Independent Submission Number_of_pages: 12 Abstract: A Request-Timeout header is defined for Hypertext Transfer Protocol (HTTP). This end-to-end header informs an origin server and any intermediaries of the maximum time that a client will await a response to its request. A server can use this header to ensure that a timely response is generated. This also identifies requests as being potentially long-lived, and allows for better resource allocation for these requests. A Connection-Timeout header is defined for HTTP. This hop-by-hop header informs the entity at the other end of a connection of the maximum time that an idle connection is kept open. This header improves reliability by providing better information about the idle connection management policy of HTTP hosts. The IETF Secretariat. --------------030303080906070800040500 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit (as individual)


Martin, Greg and I have submitted the following draft:
http://tools.ietf.org/id/draft-thomson-hybi-http-timeout-00.txt

The draft only defines HTTP headers that can be (re)used for discovery idle time to use in
both LongPolling/Comet and WebSocket connection lifetime management (keep alive process).

Note, the draft does not discuss the actual WebSocket keep alive process;
and this thread is only to discuss the mechanism for discovery idle time.


Comments and opinions on the draft are very welcome and appreciate.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com



-------- Original Message --------
Subject: New Version Notification for draft-thomson-hybi-http-timeout-00
Date: Mon, 7 Mar 2011 00:09:52 +0100
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: martin.thomson@andrew.com <martin.thomson@andrew.com>
CC: Salvatore Loreto <salvatore.loreto@ericsson.com>, "gregw@intalio.com" <gregw@intalio.com> 


A new version of I-D, draft-thomson-hybi-http-timeout-00.txt has been successfully submitted by Martin Thomson and posted to the IETF repository.

Filename:	 draft-thomson-hybi-http-timeout
Revision:	 00
Title:		 Hypertext Transfer Protocol (HTTP) Timeouts
Creation_date:	 2011-03-07
WG ID:		 Independent Submission
Number_of_pages: 12

Abstract:
A Request-Timeout header is defined for Hypertext Transfer Protocol
(HTTP).  This end-to-end header informs an origin server and any
intermediaries of the maximum time that a client will await a
response to its request.  A server can use this header to ensure that
a timely response is generated.  This also identifies requests as
being potentially long-lived, and allows for better resource
allocation for these requests.

A Connection-Timeout header is defined for HTTP.  This hop-by-hop
header informs the entity at the other end of a connection of the
maximum time that an idle connection is kept open.  This header
improves reliability by providing better information about the idle
connection management policy of HTTP hosts.
                                                                                  


The IETF Secretariat.
--------------030303080906070800040500-- From ifette@google.com Wed Mar 9 03:37:54 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634EB3A6951 for ; Wed, 9 Mar 2011 03:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.551 X-Spam-Level: X-Spam-Status: No, score=-105.551 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tQW7EpU4ihd for ; Wed, 9 Mar 2011 03:37:53 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 9E9E53A684A for ; Wed, 9 Mar 2011 03:37:52 -0800 (PST) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p29Bd4jJ012066 for ; Wed, 9 Mar 2011 03:39:07 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299670748; bh=GK9mITrsVgm4YyvSUnJ1Ld503Cw=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=JVAj7eD+wmlXBNF3hYPzy9oNqdFD3ozI4dfiupKOKVnEGZpqu+l4vMhrbyR8Zay2W r6mH2DFLxvP/mPpL643nQ== Received: from iyf40 (iyf40.prod.google.com [10.241.50.104]) by wpaz5.hot.corp.google.com with ESMTP id p29BY0bQ022719 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 9 Mar 2011 03:34:00 -0800 Received: by iyf40 with SMTP id 40so846446iyf.22 for ; Wed, 09 Mar 2011 03:34:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0uQlhJLYT20nR4+4WAoK3OuN7+wqMNN9FfHvwJikDIs=; b=DvGGhCouOqEP4WiajGt7dxTMTJm4p7QBjk3ndTc4liJ4ZXAz9oqJaFIexJH0KMYoII +Ogl6Hl+kpSL6obZWPFA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=Q/4wCd/mE+mLjMNPwDvVUkeVNfA+QNZbDqLLvdyCsORC4pO5cq9zkBtKXWf3Mo+9N0 8VHlPe7JysjpKEnHaRsA== MIME-Version: 1.0 Received: by 10.43.56.211 with SMTP id wd19mr5973736icb.91.1299670439988; Wed, 09 Mar 2011 03:33:59 -0800 (PST) Received: by 10.231.34.131 with HTTP; Wed, 9 Mar 2011 03:33:59 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Mar 2011 03:33:59 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Greg Wilkins Content-Type: multipart/alternative; boundary=bcaec51b1cfbe68f79049e0b1a1e X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 11:37:54 -0000 --bcaec51b1cfbe68f79049e0b1a1e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok, I really don't care so I will just go along here. That said, it doesn't seem like the above will let you figure out if you're looking at a masked frame or an unmasked frame. Does that matter? -Ian 2011/3/9 Greg Wilkins > I'm +1 on the proposal. > > 2011/3/9 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83= =83=E3=83=86=E3=82=A3) : > > Can someone please explain to me why this matters? > > > modified from the earlier thread on this: > > Masked Frames PROS: > + all bytes other than the key are masked. This prevents an attacker > from using frame fields like the length to send "clear text" > > Masked Frame CONS: > - Masking is not independent of framing - poor layered protocol design. > ie this is the same reason that gzip in HTTP does not change the framing > of HTTP messages. > - all WS handling that needs to be aware of frame boundaries will > need to implement masking. This will mean that more infrastructure > will have masking hard coded into it, thus it will soon become very > difficult, if not impossible to change framing as it will be baked > into WS aware intermediaries. > - Intermediaries that do not care about content will still need to > unmask and remask the frames. > - the parser/generator code for WS becomes more complex and > asymmetric because it must implement masking for some WS streams but > not for others. > - unmasking cannot be done as single optimised pass over the data, > but must be done on-the-fly in the parsing code. > - the options for masking algorithms is limited. For example session > based keys could not be used in a MUX environment as the session key > would need to be known to access the extension data to know the stream > ID, so the session ID could be known so you can't know the session > key. While session based masking may not be desirable for other > reasons, this limitation indicates a fundamental limitation of the > masked frame approach. > > > > Mask in Frame PROS: > + Masking is independent of framing. Good layered protocol design. > + Intermediaries that do not process the payload will not need to > implement masking. This saves CPU, memory and also will make it easier > to change and/or remove masking in future. > + WS parsing code is simple and symmetric. > + session based masking algorithms can be used if desired > + Can utilise the extension data space to carry the key - thus > testing the implementation of the parsing of extension data length and > preventing implementations assuming this will be zero. > > Mask in Frame CONS: > - The frame op-code, flags and length are sent in the clear. Of > these, an attacker has reasonable control over the length field, so > could conceivably send 8 characters including "GET\n" as the length > (although this would be very difficult to do via the current > javascript API. There are also simple heuristic defences for this, > such as fragmenting any frame that has a length that is all ascii and > has a CR) > > > In summary, mask in frame is far more flexible, low cost and > demonstrable better design, at cost of exposing a very very unlikely > subcase of an already very very unlikely vulnerability to an as of yet > undiscovered threat, of which an exploitable variation is already in > the wild using non ws clients. > --bcaec51b1cfbe68f79049e0b1a1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok, I really don't care so I will just go along here. That said, it doe= sn't seem like the above will let you figure out if you're looking = at a masked frame or an unmasked frame. Does that matter?

-Ian

2011/3/9 Greg Wilkins <gregw@webtide.com>
I'm +1 on the proposal.

2011/3/9 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83= =E3=83=86=E3=82=A3) <ifette@google.= com>:
> Can someone please explain to me why this matters?

modified from the earlier thread on this:

Masked Frames PROS:
=C2=A0+ all bytes other than the key are masked. =C2=A0This prevents an att= acker
from using frame fields like the length to send "clear text"

Masked Frame CONS:
=C2=A0- Masking is not independent of framing - poor layered protocol desig= n.
ie this is the same reason that gzip in HTTP does not change the framing of HTTP messages.
=C2=A0- all WS handling that needs to be aware of frame boundaries will
need to implement masking. =C2=A0This will mean that more infrastructure will have masking hard coded into it, thus it will soon become very
difficult, if not impossible to change framing as it will be baked
into WS aware intermediaries.
=C2=A0- Intermediaries that do not care about content will still need to unmask and remask the frames.
=C2=A0- the parser/generator code for WS becomes more complex and
asymmetric because it must implement masking for some WS streams but
not for others.
=C2=A0- unmasking cannot be done as single optimised pass over the data, but must be done on-the-fly in the parsing code.
=C2=A0- the options for masking algorithms is limited. =C2=A0For example se= ssion
based keys could not be used in a MUX environment as the session key
would need to be known to access the extension data to know the stream
ID, so the session ID could be known so you can't know the session
key. =C2=A0 While session based masking may not be desirable for other
reasons, this limitation indicates a fundamental limitation of the
masked frame approach.



Mask in Frame PROS:
=C2=A0+ Masking is independent of framing. =C2=A0 Good layered protocol des= ign.
=C2=A0+ Intermediaries that do not process the payload will not need to
implement masking. This saves CPU, memory and also will make it easier
to change and/or remove masking in future.
=C2=A0+ WS parsing code is simple and symmetric.
=C2=A0+ session based masking algorithms can be used if desired
=C2=A0+ Can utilise the extension data space to carry the key - thus
testing the implementation of the parsing of extension data length and
preventing implementations assuming this will be zero.

Mask in Frame CONS:
=C2=A0- The frame op-code, flags and length are sent in the clear. =C2=A0Of=
these, an attacker has reasonable control over the length field, so
could conceivably send 8 characters including "GET\n" as the leng= th
(although this would be very difficult to do via the current
javascript API. =C2=A0There are also simple heuristic defences for this, such as fragmenting any frame that has a length that is all ascii and
has a CR)


In summary, =C2=A0 mask in frame is far more flexible, low cost and
demonstrable better design, at cost of exposing a very very unlikely
subcase of an already very very unlikely vulnerability to an as of yet
undiscovered threat, of which an exploitable variation is already in
the wild using non ws clients.

--bcaec51b1cfbe68f79049e0b1a1e-- From gregw@intalio.com Wed Mar 9 03:48:06 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46DBA3A6968 for ; Wed, 9 Mar 2011 03:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wtq2uX0hLNv2 for ; Wed, 9 Mar 2011 03:48:05 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 8E6193A695F for ; Wed, 9 Mar 2011 03:48:05 -0800 (PST) Received: by vxg33 with SMTP id 33so465100vxg.31 for ; Wed, 09 Mar 2011 03:49:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.69.46 with SMTP id b14mr3793883vdu.103.1299671361417; Wed, 09 Mar 2011 03:49:21 -0800 (PST) Sender: gregw@intalio.com Received: by 10.52.169.39 with HTTP; Wed, 9 Mar 2011 03:49:21 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Mar 2011 22:49:21 +1100 X-Google-Sender-Auth: GUsr9_n8l5kzREb8hkW6y1P38Lw Message-ID: From: Greg Wilkins To: ifette@google.com Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 11:48:06 -0000 2011/3/9 Ian Fette ($B%$%"%s%U%'%C%F%#(B) : > Ok, I really don't care so I will just go along here. That said, it doesn't > seem like the above will let you figure out if you're looking at a masked > frame or an unmasked frame. Does that matter? Not to me. Even though masking IS NOT an extension, I think of it just like one. You need to have seen the handshake or some other context of the frame to know if the extension applies or not. cheers From tyoshino@google.com Wed Mar 9 04:14:00 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02D763A69A0 for ; Wed, 9 Mar 2011 04:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.476 X-Spam-Level: X-Spam-Status: No, score=-105.476 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMy-3BbILGTy for ; Wed, 9 Mar 2011 04:13:59 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 00B7F3A69A2 for ; Wed, 9 Mar 2011 04:13:57 -0800 (PST) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p29CEY82015144 for ; Wed, 9 Mar 2011 04:15:13 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299672913; bh=JbnPmorDT0vE98XDecPpkr6AlFo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=GHuPva1xd9A/kQVWtMMFBcoOOJ0CO9vx1CN1cMk8M1n2LLXh94TMm3ZiaX0kCelpo +UGAlxDEb1osy75/OlKnQ== Received: from iyj8 (iyj8.prod.google.com [10.241.51.72]) by wpaz37.hot.corp.google.com with ESMTP id p29C5Vxn017278 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 9 Mar 2011 04:06:55 -0800 Received: by iyj8 with SMTP id 8so414917iyj.9 for ; Wed, 09 Mar 2011 04:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bv+gR/L/0/g4dKGa+3A2EN6hf+UlPLXDMOx13AUndbE=; b=jkyC2tke89KTfA4Wnxu9Z7IBpvA9DULnDDRcnh8DWio0cma3QdbhIGq4tmH7B2NSu2 BJkmRZpW8Kq9Xvwd1ofA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=EO2axczDWmo94se/yeTyOwYfWwpd594oEaC8CEZudZK8K4J5x+ZVf3lqxx9x0LlOPT rWNfMdOz3qkQcy4IbRRg== Received: by 10.43.61.20 with SMTP id wu20mr7840621icb.371.1299672415177; Wed, 09 Mar 2011 04:06:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.14.141 with HTTP; Wed, 9 Mar 2011 04:06:35 -0800 (PST) In-Reply-To: <4D775D69.8010808@warmcat.com> References: <4D775D69.8010808@warmcat.com> From: Takeshi Yoshino Date: Wed, 9 Mar 2011 21:06:35 +0900 Message-ID: To: Andy Green Content-Type: multipart/alternative; boundary=bcaec51a8338a18ac5049e0b9096 X-System-Of-Record: true Cc: hybi@ietf.org, Yutaka_Takeda@playstation.sony.com Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 12:14:00 -0000 --bcaec51a8338a18ac5049e0b9096 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 9, 2011 at 19:58, Andy Green wrote: > On 03/09/2011 09:55 AM, Somebody in the thread at some point said: > >> >> This thread, too, I am wondering if this has reached a consensus at this >> point. At least, >> Greg, Brian and myself agreed to have only payload deflated. This aligns >> with the >> > > I'd be a bit happier with payload-only compression but I don't really mind. > It's a little bit less deadly than masking-outside-framing because you can > at least turn off negotiation of compression inside the standard OK if you > want to debug it. > > I prefer in-frame compression, too. I sent out a proposal http://www.ietf.org/mail-archive/web/hybi/current/msg06642.html last week. It's similar to what Yutaka explained in this thread. Comments are welcome. > reasons for choosing masking in frames, too. Also, it resolves the >> original issue Takeshi >> pointed out with regards to presence of trailing bytes after Close frame >> as in the subject >> which would cause RST in normal termination. >> > > Having implemented this now, I don't see the problem using Z_PARTIAL_FLUSH > as the standard seems to recommend normally, and then Z_FULL_FLUSH when > sending the close packet, and disabling any further packet issue on that > connection. So I don't think Takeshi's issue is more than an implementation > problem, I'd welcome being educated if I missed any point. > > Maybe, exhaustive (to be strict, recv with big buffer) recv call in your code drains all the deflated data arrived (everything including Huffman codes for some preceding frames, ones for close frame, 3 bit header BFINAL=0 BTYPE=00 and 00 00 ff ff) from the TCP stack. Yes, since it's rare that octets for a single WebSocket frame are put in separate TCP packets and delivered to application layer separately (requiring separate recv-call), this is not a big problem. But with in-frame compression, it becomes perfect. > -Andy > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --bcaec51a8338a18ac5049e0b9096 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 9, 2011 at 19:58, Andy Green <andy@w= armcat.com> wrote:
On 03/09/2011 09:55 AM, Somebody in the thread at some point said:

This thread, too, I am wondering if this has reached a consensus at this point. At least,
Greg, Brian and myself agreed to have only payload deflated. This aligns with the

I'd be a bit happier with payload-only compression but I don't real= ly mind. =A0It's a little bit less deadly than masking-outside-framing = because you can at least turn off negotiation of compression inside the sta= ndard OK if you want to debug it.
=A0

I prefer in-frame compression, to= o.

I sent out a proposal=A0http://www.ietf.org/ma= il-archive/web/hybi/current/msg06642.html=A0last week. It's similar= to what Yutaka explained in this thread. Comments are welcome.
=A0
reasons for choosing masking in frames, too. Also, it resolves the
original issue Takeshi
pointed out with regards to presence of trailing bytes after Close frame as in the subject
which would cause RST in normal termination.

Having implemented this now, I don't see the problem using Z_PARTIAL_FL= USH as the standard seems to recommend normally, and then Z_FULL_FLUSH when= sending the close packet, and disabling any further packet issue on that c= onnection. =A0So I don't think Takeshi's issue is more than an impl= ementation problem, I'd welcome being educated if I missed any point.

Maybe, exhaustive (to be strict= , recv with big buffer) recv call in your code drains all the deflated data= arrived (everything including Huffman codes for some preceding frames, one= s for close frame, 3 bit header BFINAL=3D0 BTYPE=3D00 and 00 00 ff ff) from= the TCP stack.

Yes, since it's rare that octets for a single WebSo= cket frame are put in separate TCP packets and delivered to application lay= er separately (requiring separate recv-call), this is not a big problem. Bu= t with in-frame compression, it becomes perfect.
=A0
-Andy

_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--bcaec51a8338a18ac5049e0b9096-- From tyoshino@google.com Wed Mar 9 04:17:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06B93A69A4 for ; Wed, 9 Mar 2011 04:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.547 X-Spam-Level: X-Spam-Status: No, score=-105.547 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiFEDMsMJRvz for ; Wed, 9 Mar 2011 04:17:03 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 70F383A696D for ; Wed, 9 Mar 2011 04:17:03 -0800 (PST) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p29CIIZj017680 for ; Wed, 9 Mar 2011 04:18:19 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299673099; bh=8yKiUFccgc5sxkqZxk8xtFeMKJY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=VQAvFP6BCOrgcZNk/WOihZ4B/GK8MUivO+xF8S000iLTzzl+OjxbHPrHcIoHBsgz3 22/b623m/sGsnmTupDRyQ== Received: from iwl42 (iwl42.prod.google.com [10.241.67.234]) by hpaq13.eem.corp.google.com with ESMTP id p29CIGeb029463 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 9 Mar 2011 04:18:17 -0800 Received: by iwl42 with SMTP id 42so718864iwl.17 for ; Wed, 09 Mar 2011 04:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/VieEkxehgJa1hAtbc10S5HEorF+3ayIeFm+caqDv2I=; b=EMhPpivy1D6FwWshtIH0mUSKzGdm+TOt5RaQs2A9cRKGzRpnUIRAP+smzHQ5g1bU60 AdRah12Y7PMinn4lmh5w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Jmeij0rCLIf26G+my7hsAbOEh/P/Oi3AWJugtjR8+iBQtyq8qBMi0Od6PdVNZTqRvd T5w6xWoropamNGPxMJuA== Received: by 10.43.58.197 with SMTP id wl5mr6729663icb.304.1299673096356; Wed, 09 Mar 2011 04:18:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.14.141 with HTTP; Wed, 9 Mar 2011 04:17:56 -0800 (PST) In-Reply-To: References: From: Takeshi Yoshino Date: Wed, 9 Mar 2011 21:17:56 +0900 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=bcaec517aa643b82e2049e0bb945 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] Payload only compression extension, again X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 12:17:04 -0000 --bcaec517aa643b82e2049e0bb945 Content-Type: text/plain; charset=ISO-8859-1 Thanks for feedback. On Tue, Mar 1, 2011 at 16:01, Greg Wilkins wrote: > On 1 March 2011 01:51, Takeshi Yoshino wrote: > > Hi, > > Seeing several people preferring payload only compression, I'd like to > > resume discussion on it. > > +1 > > > Requirements > > - Each message must be able to be uncompressed immediately > > +1 > > > - Want not to mess up dictionary by compressing incompressible messages > > Is that to say that you don't want to compress fragments? > I'm cautious about this as we don't want to have to buffer up all > fragments before we can decompress. > > Sorry, could you elaborate your question? I put this in the requirement since IIRC some people said that they want not to get some incompressible contents (mixed with compressible contents in a single connection) through the compressor. Like this. | WS header | BTYPE=01 | WS header | BTYPE=00 | ... > > - Want to maintain the compression state (LZ77 sliding window and > Huffman > > table) > > +1, although it might be good to have this as an extension option that > can be turned off. > I'm fine with that. > > > - Want to keep separate dictionaries for messages with different > > characteristics > > -- Case 1: Binary and text mixed > > -- Case 2: Short and long mixed > > -- Case 3: Application data in data frame and control frame may have > > different characteristics > > -1 too complex. > I think that eventually MUX will be available that will keep different > types of messages in different channels. > Until that time, I expect to see very little mixed usage on WS > connections as each usage will just open up a fresh connection. > > Good > > > > --- Apply DEFLATE only to data frame (Is it worth including control > frame?) > > +1 > > control frames should be in the clear, so that they can be considered > and handled without the need to track extension or extension state. > > > cheers > --bcaec517aa643b82e2049e0bb945 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for feedback.

On Tue, Mar 1, 2011 at 16:01, Gre= g Wilkins <gregw@= webtide.com> wrote:
On 1 March 2011 01:51, Takeshi Yoshino <tyoshino@google.com> wrote:
> Hi,
> Seeing several people preferring payload only compression, I'd lik= e to
> resume discussion on it.

+1

> Requirements
> - Each message must be able to be uncompressed=A0immediately

+1

> - Want not to mess up dictionary by compressing incompressible message= s

Is that to say that you don't want to compress fragments?
I'm cautious about this as we don't want to have to buffer up all fragments before we can decompress.


Sorry, could y= ou elaborate your question?

I put this in the requ= irement since IIRC some people said that they want not to get some incompre= ssible contents (mixed with compressible contents in a single connection) t= hrough the compressor. Like this.

| WS header | BTYPE=3D01 <compressible contents> = | WS header | BTYPE=3D00 <incompressible contents> | ...
= =A0
> - Want to maintain the compression state (LZ77 sliding window and Huff= man
> table)

+1, although it might be good to have this as an extension option tha= t
can be turned off.

I'm fine with th= at.
=A0

> - Want to keep separate dictionaries for messages with different
> characteristics
> -- Case 1: Binary and text mixed
> -- Case 2: Short and long mixed
> -- Case 3: Application data in data frame and control frame may have > different characteristics

-1 too complex.
=A0
I think that eventually MUX will be available that will keep different
types of messages in different channels.
Until that time, I expect to see very little mixed usage on WS
connections as each usage will just open up a fresh connection.


Good
=A0


> --- Apply DEFLATE only to data frame (Is it worth including control fr= ame?)

+1

control frames should be in the clear, so that they can be considered
and handled without the need to track extension or extension state.


cheers

--bcaec517aa643b82e2049e0bb945-- From andy.warmcat.com@googlemail.com Wed Mar 9 04:34:02 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D683A69A4 for ; Wed, 9 Mar 2011 04:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoFUDf3fLTfD for ; Wed, 9 Mar 2011 04:34:01 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 501453A696E for ; Wed, 9 Mar 2011 04:34:01 -0800 (PST) Received: by wyb42 with SMTP id 42so442054wyb.31 for ; Wed, 09 Mar 2011 04:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WXV2ZpOdnme7HlBlY8lNcpG3KjvaFZEa2b2W8oeR86Y=; b=QXAq3Kz0CEBAYYtlGPVPYMRkIOZGP2jYVOF8YcX7wsbwHBzwOmjQUWeh0qLg4WM1S6 /58wFTmKZNU6HOi8uoNRLUZetUJYrIN4Ya5+dHQCxdFjcVcLuXvh3OscFyBaIgJAR4Hm dxa6ieWMDDAqbQKawW52T10Ewg8MAQN3zn/KU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=U55zoC7MdFe3DVabHohpo41RNo5OnL7i82pau2Xa1saF/d7D7X3yeZeiUlM79z+mSj KP+0SOG98Ye73S9nleV6Hf+ef8K5fssz3rIxvYUghA9rfzAF8QX5yGl1YBb+35qfxYbj lDYuawrR4e37ZUeA1F13y+IfDtW+YwYWpvTXo= Received: by 10.227.139.19 with SMTP id c19mr894404wbu.13.1299674116798; Wed, 09 Mar 2011 04:35:16 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id o6sm1432134wbo.9.2011.03.09.04.35.15 (version=SSLv3 cipher=OTHER); Wed, 09 Mar 2011 04:35:15 -0800 (PST) Sender: Andy Green Message-ID: <4D777402.3010101@warmcat.com> Date: Wed, 09 Mar 2011 12:35:14 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: Takeshi Yoshino References: <4D775D69.8010808@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, Yutaka_Takeda@playstation.sony.com Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 12:34:02 -0000 On 03/09/2011 12:06 PM, Somebody in the thread at some point said: Hi - > Having implemented this now, I don't see the problem using > Z_PARTIAL_FLUSH as the standard seems to recommend normally, and > then Z_FULL_FLUSH when sending the close packet, and disabling any > further packet issue on that connection. So I don't think Takeshi's > issue is more than an implementation problem, I'd welcome being > educated if I missed any point. > > > Maybe, exhaustive (to be strict, recv with big buffer) recv call in your > code drains all the deflated data arrived (everything including Huffman > codes for some preceding frames, ones for close frame, 3 bit header > BFINAL=0 BTYPE=00 and 00 00 ff ff) from the TCP stack. Yes on both rx / inflate and tx / deflate case libwebsockets will always loop and go back to in/deflate() for the rest if the callback handling that indicates the zlib call filled its spill buffer (suggesting that it very likely has more to spill). So if there are multiple buffers full of stuff to flush in both rx or tx path they will always all get sent on the wire or sent to the user callback as uncompressed rx data before moving on. You can see the loop here for the tx path http://git.warmcat.com/cgi-bin/cgit/libwebsockets/tree/lib/parsers.c#n1378 After issuing specifically the CLOSE opcode packet like that, the connection state is changed so nothing more can be emitted on the socket, and this works reliably to issue the CLOSE to the far end for sure without further zlib housekeeping traffic or any other traffic going out. > Yes, since it's rare that octets for a single WebSocket frame are put in > separate TCP packets and delivered to application layer separately > (requiring separate recv-call), this is not a big problem. But with > in-frame compression, it becomes perfect. I think you must handle extreme compression cases anyway to keep an eye on latency if nothing else, consider he sends 200K of 0x00 and the compressor run-length encodes it, you receive a handful of compressed code bytes but must sit looping through 200K of decompressed content that represents one message. Or you pass in 1K of high quality random and 3K of codes comes out of the compressor. Like I say I think keeping framing out of compression is okay, just deflate-stream babbling after close isn't any reason for it AFAICS. -Andy From tyoshino@google.com Wed Mar 9 06:01:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298D13A69D5 for ; Wed, 9 Mar 2011 06:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.722 X-Spam-Level: X-Spam-Status: No, score=-105.722 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3f9AqBKDSP1 for ; Wed, 9 Mar 2011 06:01:24 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 57BF13A69BE for ; Wed, 9 Mar 2011 06:01:24 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p29E2ela001062 for ; Wed, 9 Mar 2011 06:02:40 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299679360; bh=3wheOmFkX0RB0KjQYtP5PRI39sY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=AjVDpBHaFCL8YrZLsNzT3/UjNN9nPC9TG6s2ssgopViw/Fi3brgBvfsKR6HMIowac fkX071+gqMh4V/y+bZolw== Received: from iwn33 (iwn33.prod.google.com [10.241.68.97]) by wpaz13.hot.corp.google.com with ESMTP id p29E2crG022315 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 9 Mar 2011 06:02:38 -0800 Received: by iwn33 with SMTP id 33so601287iwn.13 for ; Wed, 09 Mar 2011 06:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5R58R1v0yOhYRkfD1pxd1M8kznkuXwJylv36NZTxrfc=; b=Vb/9V1q8s+UO+hTBgNxXKuXEcnJqsfkXVVodLqTaynSMjGaQZroTknsdxD53434VQO QOnOyb4gZopUuZEPK3/g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Z8vTX3H23jN+HgYc9Jppl8NanzFClW6PIu0vE+xhDQdMMMIvNEOy37R8PHBusPI+G0 fabLRKh4RQw6R5sMZEZQ== Received: by 10.42.146.131 with SMTP id j3mr3175861icv.505.1299679358175; Wed, 09 Mar 2011 06:02:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.14.141 with HTTP; Wed, 9 Mar 2011 06:02:18 -0800 (PST) In-Reply-To: <4D777402.3010101@warmcat.com> References: <4D775D69.8010808@warmcat.com> <4D777402.3010101@warmcat.com> From: Takeshi Yoshino Date: Wed, 9 Mar 2011 23:02:18 +0900 Message-ID: To: Andy Green Content-Type: multipart/alternative; boundary=90e6ba21243d7749be049e0d2e2e X-System-Of-Record: true Cc: hybi@ietf.org, Yutaka_Takeda@playstation.sony.com Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:01:26 -0000 --90e6ba21243d7749be049e0d2e2e Content-Type: text/plain; charset=ISO-8859-1 Hi Andy, On Wed, Mar 9, 2011 at 21:35, Andy Green wrote: > On 03/09/2011 12:06 PM, Somebody in the thread at some point said: > > Hi - > > > Having implemented this now, I don't see the problem using >> Z_PARTIAL_FLUSH as the standard seems to recommend normally, and >> then Z_FULL_FLUSH when sending the close packet, and disabling any >> further packet issue on that connection. So I don't think Takeshi's >> issue is more than an implementation problem, I'd welcome being >> educated if I missed any point. >> >> >> Maybe, exhaustive (to be strict, recv with big buffer) recv call in your >> code drains all the deflated data arrived (everything including Huffman >> codes for some preceding frames, ones for close frame, 3 bit header >> BFINAL=0 BTYPE=00 and 00 00 ff ff) from the TCP stack. >> > > Yes on both rx / inflate and tx / deflate case libwebsockets will always > loop and go back to in/deflate() for the rest if the callback handling that > indicates the zlib call filled its spill buffer (suggesting that it very > likely has more to spill). So if there are multiple buffers full of stuff > to flush in both rx or tx path they will always all get sent on the wire or > sent to the user callback as uncompressed rx data before moving on. > > You can see the loop here for the tx path > > http://git.warmcat.com/cgi-bin/cgit/libwebsockets/tree/lib/parsers.c#n1378 > > After issuing specifically the CLOSE opcode packet like that, the > connection state is changed so nothing more can be emitted on the socket, > and this works reliably to issue the CLOSE to the far end for sure without > further zlib housekeeping traffic or any other traffic going out. > > I'm still not sure if we're on the same table. Please allow me to explain my thoughts again. Sorry if i'm misunderstanding your point. Sending a close frame is not a problem. What I'm taking as a (small, but) problem is receiving a close frame. "Trailing bytes after Close frame" in Yutaka's post doesn't mean "any further packet" or "any other traffic going" on the WebSocket layer. It means trailing bytes generated by zlib. Your code luckily drained the "close, 3 bit header, 00 00 ff ff" which contains octets generated by zlib for performing Z_FULL_FLUSH. But please imagine someone split them into two TCP packets e.g. "close codes, 3 bit header" and "00 00 ff ff" and inserted some delay between them. Your callback is run with eff_buf.token filled with "... close codes, 3 bit header", and after that your callback is run again with eff_buf.token = "00 00 ff ff". On the first run of callback, zlib can decompress all of close frame octets, but there's 00 00 ff ff left in the TCP stack, so it's not ready to issue close(2) on the socket. > > Yes, since it's rare that octets for a single WebSocket frame are put in >> separate TCP packets and delivered to application layer separately >> (requiring separate recv-call), this is not a big problem. But with >> in-frame compression, it becomes perfect. >> > > I think you must handle extreme compression cases anyway to keep an eye on > latency if nothing else, consider he sends 200K of 0x00 and the compressor > run-length encodes it, you receive a handful of compressed code bytes but > must sit looping through 200K of decompressed content that represents one > message. Or you pass in 1K of high quality random and 3K of codes comes out > of the compressor. > > Like I say I think keeping framing out of compression is okay, just > deflate-stream babbling after close isn't any reason for it AFAICS. > > -Andy > --90e6ba21243d7749be049e0d2e2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Andy,

On Wed, Mar 9, 2011 at 21:35, Andy Green <andy@warmcat.com&= gt; wrote:
On 03/09/2011 12:06 PM, Somebody in the thr= ead at some point said:

Hi -


=A0 =A0Having implemented this now, I don't see the problem using
=A0 =A0Z_PARTIAL_FLUSH as the standard seems to recommend normally, and =A0 =A0then Z_FULL_FLUSH when sending the close packet, and disabling any<= br> =A0 =A0further packet issue on that connection. =A0So I don't think Ta= keshi's
=A0 =A0issue is more than an implementation problem, I'd welcome being=
=A0 =A0educated if I missed any point.


Maybe, exhaustive (to be strict, recv with big buffer) recv call in your code drains all the deflated data arrived (everything including Huffman
codes for some preceding frames, ones for close frame, 3 bit header
BFINAL=3D0 BTYPE=3D00 and 00 00 ff ff) from the TCP stack.

Yes on both rx / inflate and tx / deflate case libwebsockets will always lo= op and go back to in/deflate() for the rest if the callback handling that i= ndicates the zlib call filled its spill buffer (suggesting that it very lik= ely has more to spill). =A0So if there are multiple buffers full of stuff t= o flush in both rx or tx path they will always all get sent on the wire or = sent to the user callback as uncompressed rx data before moving on.

You can see the loop here for the tx path

http://git.warmcat.com/cgi-bin/cgit/libwebsoc= kets/tree/lib/parsers.c#n1378

After issuing specifically the CLOSE opcode packet like that, the connectio= n state is changed so nothing more can be emitted on the socket, and this w= orks reliably to issue the CLOSE to the far end for sure without further zl= ib housekeeping traffic or any other traffic going out.


I'm still not sure if we'= ;re on the same table. Please allow me to explain my thoughts again. Sorry = if i'm misunderstanding your point.

Sending a = close frame is not a problem. What I'm taking as a (small, but) problem= is receiving a close frame. "Trailing bytes after Close frame" i= n Yutaka's post doesn't mean "any further packet" or &quo= t;any other traffic going" on the WebSocket layer. It means trailing b= ytes generated by zlib.

Your code luckily drained the "close, 3 bit = header, 00 00 ff ff" which contains octets generated by zlib for perfo= rming Z_FULL_FLUSH. But please imagine someone split them into two TCP pack= ets e.g. "close codes, 3 bit header" and "00 00 ff ff"= =A0and inserted some delay between them.=A0Your callback is run with eff_bu= f.token filled with "... close codes, 3 bit header", and after th= at your callback is run again with eff_buf.token =3D "00 00 ff ff"= ;.

On the first run of callback, zlib can decompress all o= f close frame octets, but there's 00 00 ff ff left in the TCP stack, so= it's not ready to issue close(2) on the socket.
=A0

Yes, since it's rare that octets for a single WebSocket frame are put i= n
separate TCP packets and delivered to application layer separately
(requiring separate recv-call), this is not a big problem. But with
in-frame compression, it becomes perfect.

I think you must handle extreme compression cases anyway to keep an eye on = latency if nothing else, consider he sends 200K of 0x00 and the compressor = run-length encodes it, you receive a handful of compressed code bytes but m= ust sit looping through 200K of decompressed content that represents one me= ssage. =A0Or you pass in 1K of high quality random and 3K of codes comes ou= t of the compressor.

Like I say I think keeping framing out of compression is okay, just deflate= -stream babbling after close isn't any reason for it AFAICS.

-Andy

--90e6ba21243d7749be049e0d2e2e-- From jlee@antwerkz.com Wed Mar 9 06:23:46 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC1D3A69E0 for ; Wed, 9 Mar 2011 06:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW8Yz5SA+cVY for ; Wed, 9 Mar 2011 06:23:45 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 804243A69CC for ; Wed, 9 Mar 2011 06:23:45 -0800 (PST) Received: by fxm15 with SMTP id 15so573945fxm.31 for ; Wed, 09 Mar 2011 06:25:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.30.77 with SMTP id t13mr4133538fac.112.1299680672314; Wed, 09 Mar 2011 06:24:32 -0800 (PST) Received: by 10.223.16.146 with HTTP; Wed, 9 Mar 2011 06:24:32 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Mar 2011 09:24:32 -0500 Message-ID: From: Justin Lee To: ifette@google.com Content-Type: multipart/alternative; boundary=001517448768cb76a0049e0d7c2d Cc: Hybi Subject: Re: [hybi] Browser plans? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:23:46 -0000 --001517448768cb76a0049e0d7c2d Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Great news! Just don't release before next week so I can finish my presentation without having to retool at the last minute. :) 2011/3/8 Ian Fette ($B%$%"%s%U%'%C%F%#(B) > We are in the midst of updating Chrome to -06. > > > On Tue, Mar 8, 2011 at 8:14 PM, Greg Wilkins wrote: > >> Are any browsers planning to come out with -06 support ? >> >> regards >> _______________________________________________ >> 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 > > -- You can find me on the net at: http://antwerkz.com http://www.linkedin.com/in/justinlee http://www.twitter.com/evanchooly --001517448768cb76a0049e0d7c2d Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 R3JlYXQgbmV3cyEgJm5ic3A7SnVzdCBkb24mIzM5O3QgcmVsZWFzZSBiZWZvcmUgbmV4dCB3ZWVr IHNvIEkgY2FuIGZpbmlzaCBteSBwcmVzZW50YXRpb24gd2l0aG91dCBoYXZpbmcgdG8gcmV0b29s IGF0IHRoZSBsYXN0IG1pbnV0ZS4gJm5ic3A7Oik8YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj4yMDExLzMvOCBJYW4gRmV0dGUgKBskQiUkJSIlcyVVJSclQyVGJSMbKEIpIDxzcGFuIGRp cj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmlmZXR0ZUBnb29nbGUuY29tIj5pZmV0dGVAZ29v Z2xlLmNvbTwvYT4mZ3Q7PC9zcGFuPjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFk ZGluZy1sZWZ0OjFleDsiPldlIGFyZSBpbiB0aGUgbWlkc3Qgb2YgdXBkYXRpbmcgQ2hyb21lIHRv IC0wNi48ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0iaDUiPjxicj48YnI+PGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPk9uIFR1ZSwgTWFyIDgsIDIwMTEgYXQgODoxNCBQTSwgR3JlZyBXaWxraW5z IDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWd3QGludGFsaW8uY29tIiB0 YXJnZXQ9Il9ibGFuayI+Z3JlZ3dAaW50YWxpby5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJy PgoKPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+QXJlIGFueSBi cm93c2VycyBwbGFubmluZyB0byBjb21lIG91dCB3aXRoIC0wNiBzdXBwb3J0ID88YnI+Cjxicj4K cmVnYXJkczxicj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+Cmh5YmkgbWFpbGluZyBsaXN0PGJyPgo8YSBocmVmPSJtYWlsdG86aHliaUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmh5YmlAaWV0Zi5vcmc8L2E+PGJyPgo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h5YmkiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h5Ymk8L2E+PGJyPgo8L2Jsb2NrcXVv dGU+PC9kaXY+PGJyPgo8L2Rpdj48L2Rpdj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+Cmh5YmkgbWFpbGluZyBsaXN0PGJyPgo8YSBocmVmPSJt YWlsdG86aHliaUBpZXRmLm9yZyI+aHliaUBpZXRmLm9yZzwvYT48YnI+CjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaHliaSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaHliaTwvYT48YnI+Cjxicj48L2Js b2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPllvdSBjYW4gZmlu ZCBtZSBvbiB0aGUgbmV0IGF0OjxkaXY+PGEgaHJlZj0iaHR0cDovL2FudHdlcmt6LmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly9hbnR3ZXJrei5jb208L2E+PGJyPjxhIGhyZWY9Imh0dHA6Ly93 d3cubGlua2VkaW4uY29tL2luL2p1c3RpbmxlZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cu bGlua2VkaW4uY29tL2luL2p1c3RpbmxlZTwvYT48YnI+CjxhIGhyZWY9Imh0dHA6Ly93d3cudHdp dHRlci5jb20vZXZhbmNob29seSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cudHdpdHRlci5j b20vZXZhbmNob29seTwvYT48L2Rpdj48YnI+Cg== --001517448768cb76a0049e0d7c2d-- From andy.warmcat.com@googlemail.com Wed Mar 9 06:30:44 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E64F3A69FC for ; Wed, 9 Mar 2011 06:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFWc-tM0Jxjc for ; Wed, 9 Mar 2011 06:30:43 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E6CAD3A69E4 for ; Wed, 9 Mar 2011 06:30:42 -0800 (PST) Received: by wwa36 with SMTP id 36so444615wwa.13 for ; Wed, 09 Mar 2011 06:31:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8ZLugNJu0yi3OTv53lnkuwMbkIqezFoMCbrej2IVzaY=; b=MiscVLZfwoBIgTAx1+Jp500rmCiYOhORyx4YW5cv9VZOSn1QocVcjHfhCz4dXc+GPE iXjYlJAUjApSyao5Y9aQq98EG9IPEngLQEDG7AF5RzrOFRJOYxUwqAnL5D31Tws06jE6 gsMeG+TTYO6ek0WdiLZRmbVoxyXa/WQQ0Kdf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=oBs2pfjK5TwBVSAYB2jWGhSKZFAA1jKixp5uZT9yddEQZbzIpn2bA1no+5/JYYBLQo NNtReynZc03TKyrjPOC8RDrRyy6K7MQKruvcUF0/Ywi5nI0QEm6DYTvFo4fdJEl/l+4l GjAHE500PEDvnFUy5pwku0bSML2KzrFw3JzAA= Received: by 10.227.165.194 with SMTP id j2mr5826701wby.178.1299681118761; Wed, 09 Mar 2011 06:31:58 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id x1sm1507210wbh.20.2011.03.09.06.31.57 (version=SSLv3 cipher=OTHER); Wed, 09 Mar 2011 06:31:57 -0800 (PST) Sender: Andy Green Message-ID: <4D778F5C.3020404@warmcat.com> Date: Wed, 09 Mar 2011 14:31:56 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: Takeshi Yoshino References: <4D775D69.8010808@warmcat.com> <4D777402.3010101@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, Yutaka_Takeda@playstation.sony.com Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:30:44 -0000 On 03/09/2011 02:02 PM, Somebody in the thread at some point said: Hi - > I'm still not sure if we're on the same table. Please allow me to > explain my thoughts again. Sorry if i'm misunderstanding your point. > > Sending a close frame is not a problem. What I'm taking as a (small, OK. > but) problem is receiving a close frame. "Trailing bytes after Close > frame" in Yutaka's post doesn't mean "any further packet" or "any other > traffic going" on the WebSocket layer. It means trailing bytes generated > by zlib. > > Your code luckily drained the "close, 3 bit header, 00 00 ff ff" which > contains octets generated by zlib for performing Z_FULL_FLUSH. But > please imagine someone split them into two TCP packets e.g. "close > codes, 3 bit header" and "00 00 ff ff" and inserted some delay between OK. > them. Your callback is run with eff_buf.token filled with "... close > codes, 3 bit header", and after that your callback is run again with > eff_buf.token = "00 00 ff ff". OK I think I get your idea. So it is possible at the receiver I get enough zlib codes in one packet that it emits the full close frame decompressed from inflate(), and I go off and interpret that and try to close the socket, but there is already some "dribble" from zlib in flight in a second packet which never gets serviced then. The only thing is I set it to do Z_PARTIAL_FLUSH after every input is added to the compressor. So it means the compressor cannot be holding much of anything at the time we come and ask it to send the CLOSE frame with Z_FULL_FLUSH. CLOSE frame is limited to 125 payload. So it seems it would always issue one final compressed output buffer in this case, including zlib trailer, which translates to one packet on the wire reliably. I'm also using TCP_NODELAY to stop it aggregating packets and causing latency. I agree it is a theoretical opportunity for something else to fragment the packet and make the situation you're describing, but I can't see it happening the thing is on a link with like 30-40 byte MTU which is what is needed including TCP /IP headers to break the packet there. Are there other circumstances that can actually cause this I'm overlooking too easily? Thanks for explaining your meaning to me. -Andy From tyoshino@google.com Wed Mar 9 07:48:33 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37B73A6859 for ; Wed, 9 Mar 2011 07:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.738 X-Spam-Level: X-Spam-Status: No, score=-105.738 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS7CwrwpEEwP for ; Wed, 9 Mar 2011 07:48:31 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8536D3A6A2E for ; Wed, 9 Mar 2011 07:48:31 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p29FnlIC026273 for ; Wed, 9 Mar 2011 07:49:47 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299685787; bh=/4i2Lh+lhAQDftw++NCdVKzk49E=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=A7pP9f4/17s4OSUWvlxZZ05T3ZZ2w/K0csTUq2q7/81EaA3yBtN8AEG5xhYU+94u5 V31b1EP0zGPTPfJk34ipQ== Received: from iym7 (iym7.prod.google.com [10.241.52.7]) by wpaz17.hot.corp.google.com with ESMTP id p29Fn3mf008364 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 9 Mar 2011 07:49:46 -0800 Received: by iym7 with SMTP id 7so857909iym.18 for ; Wed, 09 Mar 2011 07:49:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qwhmXcZ8uwVtj3Ig05hetsBsf6prW0u7t63FG5UQ7wI=; b=AFcXOdzC7RlKABghM+5lLaRVHX72hSlSI2LMhDxwF/fJTQYgq2BJ/aK/wSn4bOtYtm tjaySqe9KD2+5lerymVw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=T+wij6LNxqAFPR1Zh36GZ5Gd0ADfGsQ1w6/yKoR3SNryVAeSh5tWfYPqLIdEhJb2VK 0xcboN0V5/0XCN+Gwx2g== Received: by 10.43.61.20 with SMTP id wu20mr8163840icb.371.1299685786135; Wed, 09 Mar 2011 07:49:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.14.141 with HTTP; Wed, 9 Mar 2011 07:49:26 -0800 (PST) In-Reply-To: <4D778F5C.3020404@warmcat.com> References: <4D775D69.8010808@warmcat.com> <4D777402.3010101@warmcat.com> <4D778F5C.3020404@warmcat.com> From: Takeshi Yoshino Date: Thu, 10 Mar 2011 00:49:26 +0900 Message-ID: To: Andy Green Content-Type: multipart/alternative; boundary=bcaec51a83389a2e6d049e0eada5 X-System-Of-Record: true Cc: hybi@ietf.org, Yutaka_Takeda@playstation.sony.com Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:48:33 -0000 --bcaec51a83389a2e6d049e0eada5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 9, 2011 at 23:31, Andy Green wrote: > On 03/09/2011 02:02 PM, Somebody in the thread at some point said: > > Hi - > > I'm still not sure if we're on the same table. Please allow me to >> explain my thoughts again. Sorry if i'm misunderstanding your point. >> >> Sending a close frame is not a problem. What I'm taking as a (small, >> > > OK. > > > but) problem is receiving a close frame. "Trailing bytes after Close >> frame" in Yutaka's post doesn't mean "any further packet" or "any other >> traffic going" on the WebSocket layer. It means trailing bytes generated >> by zlib. >> >> Your code luckily drained the "close, 3 bit header, 00 00 ff ff" which >> contains octets generated by zlib for performing Z_FULL_FLUSH. But >> please imagine someone split them into two TCP packets e.g. "close >> codes, 3 bit header" and "00 00 ff ff" and inserted some delay between >> > > OK. > > > them. Your callback is run with eff_buf.token filled with "... close >> codes, 3 bit header", and after that your callback is run again with >> eff_buf.token = "00 00 ff ff". >> > > OK I think I get your idea. So it is possible at the receiver I get enough > zlib codes in one packet that it emits the full close frame decompressed > from inflate(), and I go off and interpret that and try to close the socket, > but there is already some "dribble" from zlib in flight in a second packet > which never gets serviced then. > Yes! > > The only thing is I set it to do Z_PARTIAL_FLUSH after every input is added > to the compressor. So it means the compressor cannot be holding much of > anything at the time we come I'm doing the same in pywebsocket (using Z_SYNC_FLUSH). > and ask it to send the CLOSE frame with Z_FULL_FLUSH. Yes, too (Z_SYNC_FLUSH). > CLOSE frame is limited to 125 payload. So it seems it would always issue > one final compressed output buffer in this case, including zlib trailer, > which translates to one packet on the wire reliably. I'm also using > TCP_NODELAY to stop it aggregating packets and causing latency. > It makes sense. > > I agree it is a theoretical opportunity for something else to fragment the > packet and make the situation you're describing, but I can't see it > happening the thing is on a link with like 30-40 byte MTU which is what is > needed including TCP /IP headers to break the packet there. > > Yes. Because of that, I'm not so eager to push this idea... But if we can have better one, I think it's nice. One method I can come up with - by which we can make sure that we recv all the data zlib emit - that can be applied to stream-based deflate is putting BFINAL=1 block at the end of stream. zlib does this when Z_FINISH is specified. That block contains full or some portion of close frame octets or even empty one after close codes is ok. zlib returns EoF by some manner when it consumed all the data terminated by BFINAL=1 block. python's zlib wrapper doesn't have API to probe EoF now, so I can't apply this to pywebsocket, but it seems it's applicable on many environment (original C zlib, Java, etc.) > Are there other circumstances that can actually cause this I'm overlooking > too easily? Thanks for explaining your meaning to me. > No problem. Thanks. > > -Andy > --bcaec51a83389a2e6d049e0eada5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 9, 2011 at 23:31, Andy Green <andy@warmcat.com>= wrote:
On 03/09/2011 02:02 PM, Somebody in the thread at some po= int said:

Hi -

I'm still not sure if we're on the same table. Please allow me to explain my thoughts again. Sorry if i'm misunderstanding your point.
Sending a close frame is not a problem. What I'm taking as a (small,

OK.


but) problem is receiving a close frame. "Trailing bytes after Close frame" in Yutaka's post doesn't mean "any further packet&= quot; or "any other
traffic going" on the WebSocket layer. It means trailing bytes generat= ed
by zlib.

Your code luckily drained the "close, 3 bit header, 00 00 ff ff" = which
contains octets generated by zlib for performing Z_FULL_FLUSH. But
please imagine someone split them into two TCP packets e.g. "close
codes, 3 bit header" and "00 00 ff ff" and inserted some del= ay between

OK.


them. Your callback is run with eff_buf.token filled with "... close codes, 3 bit header", and after that your callback is run again with eff_buf.token =3D "00 00 ff ff".

OK I think I get your idea. =A0So it is possible at the receiver I get enou= gh zlib codes in one packet that it emits the full close frame decompressed= from inflate(), and I go off and interpret that and try to close the socke= t, but there is already some "dribble" from zlib in flight in a s= econd packet which never gets serviced then.
Yes!
=A0

The only thing is I set it to do Z_PARTIAL_FLUSH after every input is added= to the compressor. =A0So it means the compressor cannot be holding much of= anything at the time we come

I'm doin= g the same in pywebsocket (using Z_SYNC_FLUSH).
=A0
and ask it to send the CLOSE = frame with Z_FULL_FLUSH.

Yes, too (Z_SYNC_= FLUSH).
=A0
=A0CLOSE frame is limited to = 125 payload. =A0So it seems it would always issue one final compressed outp= ut buffer in this case, including zlib trailer, which translates to one pac= ket on the wire reliably. =A0I'm also using TCP_NODELAY to stop it aggr= egating packets and causing latency.
It makes sense.
=A0

I agree it is a theoretical opportunity for something else to fragment the = packet and make the situation you're describing, but I can't see it= happening the thing is on a link with like 30-40 byte MTU which is what is= needed including TCP /IP headers to break the packet there.

Yes. Because of that, I'm not so eager to push th= is idea... But if we can have better one, I think it's nice.
=
One method I can come up with
- by which we can ma= ke sure that we recv all the data zlib emit
- that can be applied to stream-based deflate
is putting BFI= NAL=3D1 block at the end of stream.=A0zlib does this when Z_FINISH is speci= fied.=A0That block contains full or some portion of close frame octets or e= ven empty one after close codes is ok. zlib returns EoF by some manner when= it consumed all the data terminated by BFINAL=3D1 block.

python's zlib wrapper doesn't have API to probe= EoF now, so I can't apply this to pywebsocket, but it seems it's a= pplicable on many environment (original C zlib, Java, etc.)
=A0
Are there other circumstances that can actually cause this I'm overlook= ing too easily? =A0Thanks for explaining your meaning to me.
No problem. Thanks.
=A0

-Andy

--bcaec51a83389a2e6d049e0eada5-- From bruce@callenish.com Wed Mar 9 09:26:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFDFC3A6814 for ; Wed, 9 Mar 2011 09:26:21 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hwcDwwFZMDI for ; Wed, 9 Mar 2011 09:26:20 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 81B4A3A6765 for ; Wed, 9 Mar 2011 09:26:20 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.103]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1PxNAb-0007H4-01; Wed, 09 Mar 2011 09:27:33 -0800 Message-ID: <4D77B885.5050109@callenish.com> Date: Wed, 09 Mar 2011 09:27:33 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: ifette@google.com References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 17:26:22 -0000 On 09/03/2011 3:33 AM, Ian Fette (イアンフェッティ) wrote: > Ok, I really don't care so I will just go along here. That said, it > doesn't seem like the above will let you figure out if you're looking > at a masked frame or an unmasked frame. Does that matter? > > It does to me and (I think) Andy, but we were the lone voices willing to use a reserved bit for this. Without more support I am ready to admit defeat on this point. From andy.warmcat.com@googlemail.com Wed Mar 9 09:58:10 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 288A33A6765 for ; Wed, 9 Mar 2011 09:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufYOWEJk0QdE for ; Wed, 9 Mar 2011 09:58:09 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 98E6D3A67EE for ; Wed, 9 Mar 2011 09:58:08 -0800 (PST) Received: by wyb42 with SMTP id 42so776495wyb.31 for ; Wed, 09 Mar 2011 09:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2SRXo7bJ8DnK0xFDuGFfnV3mUIjHRU+YBeen1nOJwls=; b=EFcjou8ObXs9uHnKCgef/44hLRlxtnYakg627FGBj8dXpTRKfz+ikQLMOGki+V1ry8 0MtIqCYQyvfgRisbKs/j6qUvgp8EEdf/yRmqvQYIr6SZS8CTuqXEou0f+LdmMYMUVR15 APNmiYi0y627zajXTDM7cSOpSKhAImDddz124= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=myNFRwv41wgXobW3NqzaMf8KiekEzQg/g7WpmBIAN9uPL8WYzfrAdp4BZEkZgyIJrk ybHNtbDG+c3OJz37LKqG8I+vxCB71egbumAb+isBJahhNOMHW9u+6fFQE1j8M7PkW/52 JG2X98ozBGbbIESphB3F9tLigM3XvqNwG2kq8= Received: by 10.227.61.16 with SMTP id r16mr6019235wbh.24.1299693564679; Wed, 09 Mar 2011 09:59:24 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id x1sm1657664wbh.14.2011.03.09.09.59.23 (version=SSLv3 cipher=OTHER); Wed, 09 Mar 2011 09:59:23 -0800 (PST) Sender: Andy Green Message-ID: <4D77BFFA.7070808@warmcat.com> Date: Wed, 09 Mar 2011 17:59:22 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: Bruce Atherton References: <4D77B885.5050109@callenish.com> In-Reply-To: <4D77B885.5050109@callenish.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 17:58:10 -0000 On 03/09/2011 05:27 PM, Somebody in the thread at some point said: > On 09/03/2011 3:33 AM, Ian Fette (イアンフェッティ) wrote: >> Ok, I really don't care so I will just go along here. That said, it >> doesn't seem like the above will let you figure out if you're looking >> at a masked frame or an unmasked frame. Does that matter? >> >> > > It does to me and (I think) Andy, but we were the lone voices willing to Yes you're right I also think it'd be good to burn a bit for masked. We're already sending those reserved bits. Actually, I know it's a bit off-topic and not for -07, but when I was doing extensions stuff for libwebsocket I was curious and having to make guesses about the kind of approach mux extension will take. I don't want to argue about it now, it'd just be interesting to take the temperature of people (or person, John) who thought ahead on it already. Eg, you get a byte in extended area telling the channel and coding channel bringup and shutdown events? > use a reserved bit for this. Without more support I am ready to admit > defeat on this point. Right I heard people carefully reserving the extended bits but if we reserve them all at 0 forever in all contexts we will be wasting them alright. -Andy From Yutaka_Takeda@PlayStation.Sony.Com Wed Mar 9 10:40:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BBE93A6933 for ; Wed, 9 Mar 2011 10:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAoUctl81HEh for ; Wed, 9 Mar 2011 10:40:14 -0800 (PST) Received: from paris.playstation.sony.com (nat.playstation.sony.com [69.36.131.254]) by core3.amsl.com (Postfix) with ESMTP id 57BCB3A692A for ; Wed, 9 Mar 2011 10:40:13 -0800 (PST) Received: from constantine.playstation.sony.com ([162.49.67.15]) by paris.playstation.sony.com (Lotus Domino Release 8.5.1FP5) with ESMTP id 2011030910412852-243206 ; Wed, 9 Mar 2011 10:41:28 -0800 In-Reply-To: <4D77B885.5050109@callenish.com> To: Bruce Atherton MIME-Version: 1.0 X-KeepSent: 36FEDDC6:06951577-8825784E:0062343E; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Yutaka_Takeda@PlayStation.Sony.Com Date: Wed, 9 Mar 2011 10:41:25 -0800 X-MIMETrack: Serialize by Router on SCEA919ML04/SCEA(Release 8.5.1FP3|May 23, 2010) at 03/09/2011 10:41:28 AM, Serialize complete at 03/09/2011 10:41:28 AM, Itemize by SMTP Server on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/09/2011 10:41:28 AM, Serialize by Router on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/09/2011 10:41:31 AM, Serialize complete at 03/09/2011 10:41:31 AM Content-Type: multipart/alternative; boundary="=_alternative 0066AC238825784E_=" Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 18:40:15 -0000 This is a multipart message in MIME format. --=_alternative 0066AC238825784E_= Content-Type: text/plain; charset="ISO-2022-JP" > On 09/03/2011 3:33 AM, Ian Fette ($B%$%"%s%U%'%C%F%#(B) wrote: > > Ok, I really don't care so I will just go along here. That said, it > > doesn't seem like the above will let you figure out if you're looking > > at a masked frame or an unmasked frame. Does that matter? > > > > > > It does to me and (I think) Andy, but we were the lone voices willing to > use a reserved bit for this. Without more support I am ready to admit > defeat on this point. Let me join in the voices for +1 on the use of reserved bit. I agree with your points of debate in the following messages: - http://www.ietf.org/mail-archive/web/hybi/current/msg06631.html - http://www.ietf.org/mail-archive/web/hybi/current/msg06633.html Reasons: o Sniffers can choose whether to go ahead and parse masked payload based on the bit without having to capture from the start. (It greatly helps us in debugging or trouble shooting) o Ability to turn off masking for debugging/trouble shooting. (this should not be manipulable by user code, of course, just to be clear) o It is worthier allocating a bit for this than reserving it for something we don't even know especially when we still have at least a few bits left. o Lacking the bit seems to be the source of sense of asymmetry - as in the frame not being self-descriptive for what's in the payload (not to be confused by 'understanding' the payload), seems to be a bad protocol design choice. - Yutaka --=_alternative 0066AC238825784E_= Content-Type: text/html; charset="ISO-2022-JP"

> On 09/03/2011 3:33 AM, Ian Fette ($B%$%"%s%U%'%C%F%#(B) wrote:
> > Ok, I really don't care so I will just go along here. That said, it
> > doesn't seem like the above will let you figure out if you're looking
> > at a masked frame or an unmasked frame. Does that matter?
> >
> >
>
> It does to me and (I think) Andy, but we were the lone voices willing to
> use a reserved bit for this. Without more support I am ready to admit
> defeat on this point.
Let me join in the voices for +1 on the use of reserved bit.

I agree with your points of debate in the following messages:
 - http://www.ietf.org/mail-archive/web/hybi/current/msg06631.html
 - http://www.ietf.org/mail-archive/web/hybi/current/msg06633.html

Reasons:

 o Sniffers can choose whether to go ahead and parse masked payload
   based on the bit without having to capture from the start.
   (It greatly helps us in debugging or trouble shooting)
 o Ability to turn off masking for debugging/trouble shooting.
   (this should not be manipulable by user code, of course, just to be clear)
 o It is worthier allocating a bit for this than reserving it
   for something we don't even know especially when we still have
   at least a few bits left.
 o Lacking the bit seems to be the source of sense of asymmetry -
   as in the frame not being self-descriptive for what's in the
   payload (not to be confused by 'understanding' the payload),
   seems to be a bad protocol design choice.


- Yutaka
--=_alternative 0066AC238825784E_=-- From jat@google.com Wed Mar 9 11:03:50 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6780D3A6965 for ; Wed, 9 Mar 2011 11:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.815 X-Spam-Level: X-Spam-Status: No, score=-105.815 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4km1NlSkEVHW for ; Wed, 9 Mar 2011 11:03:49 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id A9FBF3A680F for ; Wed, 9 Mar 2011 11:03:48 -0800 (PST) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p29J54Se026642 for ; Wed, 9 Mar 2011 11:05:04 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299697504; bh=Ksxzvaax9b2J5bGrMJIeZENqSng=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=veVzgbkwWYZ/ze+hrjOKeeiRrzSE8oUnnc98aBX92H5rY8mNyHvHCChwB6eDpatIZ 5YWdERnMX+ntMB/wkQucg== Received: from ywg4 (ywg4.prod.google.com [10.192.7.4]) by wpaz37.hot.corp.google.com with ESMTP id p29J4oJu031018 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 9 Mar 2011 11:05:03 -0800 Received: by ywg4 with SMTP id 4so429875ywg.24 for ; Wed, 09 Mar 2011 11:05:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qcC7dzzZbsVpD5oqS2ovUqAN7L8fI9mXYqI6NLmDMok=; b=xdSaHN/nDPVR2Rdl6apHHyOj/J5OlLgLE0a7KPHcmmX/W2xJqAZIJja6+YgvtMHMeu 5r9alWYMtRNpKI0jcnfQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Seq9USc/fCTQ5CLvJ5Lq1FQuq9vNBkxFU/Tp3NaWVdWc2f7QSdJjjIntkMqrqFYGCK ixecfBlMrpfGRsMlQ1ow== Received: by 10.150.99.19 with SMTP id w19mr8046096ybb.295.1299697501105; Wed, 09 Mar 2011 11:05:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Wed, 9 Mar 2011 11:04:41 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> From: John Tamplin Date: Wed, 9 Mar 2011 14:04:41 -0500 Message-ID: To: Yutaka_Takeda@playstation.sony.com Content-Type: multipart/alternative; boundary=000e0cd299a8de6ed7049e116721 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 19:03:50 -0000 --000e0cd299a8de6ed7049e116721 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 9, 2011 at 1:41 PM, wrote: > Let me join in the voices for +1 on the use of reserved bit. > > I agree with your points of debate in the following messages: > - http://www.ietf.org/mail-archive/web/hybi/current/msg06631.html > - http://www.ietf.org/mail-archive/web/hybi/current/msg06633.html > > Reasons: > > o Sniffers can choose whether to go ahead and parse masked payload > based on the bit without having to capture from the start. > (It greatly helps us in debugging or trouble shooting) > I agree this is useful, but I disagree that this is sufficient to warrant the cost. > o Ability to turn off masking for debugging/trouble shooting. > (this should not be manipulable by user code, of course, just to be > clear) > This is orthogonal to whether to use a bit in the frame, and from previous discussions there is little support for being able to disable it. > o It is worthier allocating a bit for this than reserving it > for something we don't even know especially when we still have > at least a few bits left. > The problem is there are only a few reserved bits, and we don't know how many it would be useful to have. One thing that was discussed earlier that would require allocation of a reserved bit would be per-frame compression, so you can avoid compressing non-compressible data. Another possibility is that we generally allocate more opcodes for extensions, in which case we would like to be able to allocate some of the reserved bits to the opcode field. We won't know we used too many until we need more than we have, at which point it becomes expensive (50% additional overhead for small frames) to get more. When we came up with this framing, this was the compromise between cost and leaving options open for the future that everybody could live with. Think about it from an efficiency point of view -- you are suggesting allocating a bit in every frame that is going to be the same for every frame in the same direction. How can that possibly be good stewardship of limited resources, rather than specifying it once in the header (or not at all if it is known to be set or clear based on which side is initiating the connection)? o Lacking the bit seems to be the source of sense of asymmetry - > as in the frame not being self-descriptive for what's in the > payload (not to be confused by 'understanding' the payload), > seems to be a bad protocol design choice. > The frame is already not self-descriptive -- if compression is negotiated, you have to know that (plus the current compression state) in order to interpret the frames. Likewise, other extensions will likely modify interpretation of the payload. I still think it is not worth allocating a reserved bit to indicate masking is present, but if most people want it I won't object too strenuously. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd299a8de6ed7049e116721 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 9, 2011 at 1:41 PM, <Yutaka_Takeda@= playstation.sony.com> wrote:
Let me join in the voices for +1 on = the use of reserved bit.

I agree with your points of debate in the followin= g messages:
=C2=A0- http://www.ietf.org/mai= l-archive/web/hybi/current/msg06631.html
=C2=A0- http://www.ietf.org/mai= l-archive/web/hybi/current/msg06633.html

Reasons:

=C2=A0o Sniffers can choose whether to go ahead an= d parse masked payload
=C2=A0 =C2=A0based on the bit without having to ca= pture from the start.
=C2=A0 =C2=A0(It greatly helps us in debugging or trouble shooting)

I agree this is useful, but I disagree= that this is sufficient to warrant the cost.
=C2=A0
=C2=A0o Ability to turn off masking for debugging/trou= ble shooting.
=C2=A0 =C2=A0(this should not be manipulable by us= er code, of course, just to be clear)

This is orthogonal to whether to use a= bit in the frame, and from previous discussions there is little support fo= r being able to disable it.
=C2=A0
=C2=A0o It is worthier allocating a bit for this than reserving it
=C2=A0 =C2=A0for something we don't even know = especially when we still have
=C2=A0 =C2=A0at least a few bits left.

The problem is there are only a few re= served bits, and we don't know how many it would be useful to have. =C2= =A0One thing that was discussed earlier that would require allocation of a = reserved bit would be per-frame compression, so you can avoid compressing n= on-compressible data. =C2=A0Another possibility is that we generally alloca= te more opcodes for extensions, in which case we would like to be able to a= llocate some of the reserved bits to the opcode field. =C2=A0We won't k= now we used too many until we need more than we have, at which point it bec= omes expensive (50% additional overhead for small frames) to get more. =C2= =A0When we came up with this framing, this was the compromise between cost = and leaving options open for the future that everybody could live with.
=C2=A0
Think about it from an efficiency point of view -- yo= u are suggesting allocating a bit in every frame that is going to be the sa= me for every frame in the same direction. =C2=A0How can that possibly be go= od stewardship of limited resources, rather than specifying it once in the = header (or not at all if it is known to be set or clear based on which side= is initiating the connection)?

=C2=A0o= Lacking the bit seems to be the source of sense of asymmetry -
=C2=A0 =C2=A0as in the frame not being self-descri= ptive for what's in the
=C2=A0 =C2=A0payload (not to be confused by 'u= nderstanding' the payload),
=C2=A0 =C2=A0seems to be a bad protocol design cho= ice.
=C2=A0
The frame is already not self-descr= iptive -- if compression is negotiated, you have to know that (plus the cur= rent compression state) in order to interpret the frames. =C2=A0Likewise, o= ther extensions will likely modify interpretation of the payload.

I still think it is not worth allocating a reserved bit to indicat= e masking is present, but if most people want it I won't object too str= enuously.

--
John A. Tamplin
Software Engineer (GWT), = Google
--000e0cd299a8de6ed7049e116721-- From gregw@intalio.com Wed Mar 9 12:32:27 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654933A6969 for ; Wed, 9 Mar 2011 12:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qe7fDQ8XuVDv for ; Wed, 9 Mar 2011 12:32:26 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 943623A69FD for ; Wed, 9 Mar 2011 12:32:26 -0800 (PST) Received: by vxg33 with SMTP id 33so1036818vxg.31 for ; Wed, 09 Mar 2011 12:33:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.69.46 with SMTP id b14mr4712976vdu.103.1299702821896; Wed, 09 Mar 2011 12:33:41 -0800 (PST) Sender: gregw@intalio.com Received: by 10.52.169.39 with HTTP; Wed, 9 Mar 2011 12:33:41 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> Date: Thu, 10 Mar 2011 07:33:41 +1100 X-Google-Sender-Auth: vj1nQFicB11WZ3UGXQnhu7qGquc Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi , Yutaka_Takeda@playstation.sony.com Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:32:27 -0000 I'm +1 for using a reserved bit to indicate masking, but not if that clouds any consensus for in frame masking. Besides, the way the protocol is developing, we are allocated data space for control codes, for masks etc. then most extensions will be free to put bits there. For me, the only reason to use reserve bits instead of payload bits, is that it is much much simpler for the framing layer to interpret those bits. ie you couldn't have a masking bit inside a masked payload. So I think masking is a perfect exemplar for the use of a reserve bit. If it can't get over the line, then I doubt any usage can. cheers From gregw@intalio.com Wed Mar 9 12:34:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F73B3A6AB8 for ; Wed, 9 Mar 2011 12:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCiWMubQs15P for ; Wed, 9 Mar 2011 12:34:47 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 7E3DD3A6AB5 for ; Wed, 9 Mar 2011 12:34:47 -0800 (PST) Received: by vxg33 with SMTP id 33so1039756vxg.31 for ; Wed, 09 Mar 2011 12:36:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.180.166 with SMTP id dp6mr6597050vdc.63.1299702964080; Wed, 09 Mar 2011 12:36:04 -0800 (PST) Sender: gregw@intalio.com Received: by 10.52.169.39 with HTTP; Wed, 9 Mar 2011 12:36:04 -0800 (PST) In-Reply-To: References: Date: Thu, 10 Mar 2011 07:36:04 +1100 X-Google-Sender-Auth: SEjmLXzCTw3fy5kEzo0FbJOVRVI Message-ID: From: Greg Wilkins To: Takeshi Yoshino Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] Payload only compression extension, again X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:34:48 -0000 On 9 March 2011 23:17, Takeshi Yoshino wrote: > Thanks for feedback. > On Tue, Mar 1, 2011 at 16:01, Greg Wilkins wrote: >> >> On 1 March 2011 01:51, Takeshi Yoshino wrote: >> > Hi, > >> > - Want not to mess up dictionary by compressing incompressible messages >> >> Is that to say that you don't want to compress fragments? >> I'm cautious about this as we don't want to have to buffer up all >> fragments before we can decompress. >> > > Sorry, could you elaborate your question? > I put this in the requirement since IIRC some people said that they want not > to get some incompressible contents (mixed with compressible contents in a > single connection) through the compressor. Like this. > | WS header | BTYPE=01 | WS header | BTYPE=00 > | ... thanks - that answers my question fine. cheers From jat@google.com Wed Mar 9 12:39:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95B33A69FD for ; Wed, 9 Mar 2011 12:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.82 X-Spam-Level: X-Spam-Status: No, score=-105.82 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdZRq164vIkv for ; Wed, 9 Mar 2011 12:39:12 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 3CA1A3A6989 for ; Wed, 9 Mar 2011 12:39:12 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p29KeRbH011301 for ; Wed, 9 Mar 2011 12:40:28 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299703228; bh=XZcNTcuOic2hSFYPvcGzYQK50OY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=qXDgn10gufDHsYdqEiIMUYXV4T7lqfObU0qdo4OP+KLvtXllmNOJiFAFfXOM0cBeq aS9Z8uhHeQ1dlsBQSFztw== Received: from yib2 (yib2.prod.google.com [10.243.65.66]) by wpaz13.hot.corp.google.com with ESMTP id p29KcVJ2003448 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 9 Mar 2011 12:40:26 -0800 Received: by yib2 with SMTP id 2so427871yib.38 for ; Wed, 09 Mar 2011 12:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fbGXkB1P4jzX4XXcv3h+zMVY7mqSLC78J5AdAsWFedk=; b=hJy2CnPtv0DkeB9Y/xNxTDZUhjVErjUjvecRVB8SX9CI3a2+8vzI3MsUDDAuBP4ZYu eDJINbOBdDRb3ngdfWMw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=V0QimvK4EzKBmGiyyskIr0aXvTbxe//Htbu4+R7+vpVJFhzLaBIA6iXdc10GhaHLtz fjcHMBdrhRb7UqlBGj4Q== Received: by 10.150.162.2 with SMTP id k2mr8355514ybe.10.1299703226193; Wed, 09 Mar 2011 12:40:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Wed, 9 Mar 2011 12:40:06 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> From: John Tamplin Date: Wed, 9 Mar 2011 15:40:06 -0500 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd60ae41c5896049e12bdf7 X-System-Of-Record: true Cc: Hybi , Yutaka_Takeda@playstation.sony.com Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:39:13 -0000 --000e0cd60ae41c5896049e12bdf7 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 9, 2011 at 3:33 PM, Greg Wilkins wrote: > So I think masking is a perfect exemplar for the use of a reserve bit. > If it can't get over the line, then I doubt any usage can. > Assuming the browser vendors stick to the requirement that client-side masking is mandatory, then every single MASKED bit will be set on the client->server side, and either all will be set or all will be cleared on the server side of the connection. The receiver knows without a doubt the state of masking for the next frame it will receive (and should drop the connection if that expectation isn't met). That doesn't seem like a useful candidate to have something that doesn't change in every single frame, when the sole benefit of it is for debugging. Compare that to allocating a bit to show a frame is compressed -- we certainly know that some messages will be compressible (text), while others won't (images, audio, pre-compressed data, etc). The receiver has no way of knowing ahead of time which sort of message will next be sent, so it makes sense to allocate a bit to say whether this frame was compressed or not. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd60ae41c5896049e12bdf7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 9, 2011 at 3:33 PM, Greg Wilkins <gregw@webtide.com> wrote:
So I think masking is a perfect exemplar for the use of a reserve bit.
=C2=A0If it can't get over the line, then I doubt any usage can.


Compare that to allocating a bit to show a frame is com= pressed -- we certainly know that some messages will be compressible (text)= , while others won't (images, audio, pre-compressed data, etc). =C2=A0T= he receiver has no way of knowing ahead of time which sort of message will = next be sent, so it makes sense to allocate a bit to say whether this frame= was compressed or not.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd60ae41c5896049e12bdf7-- From Yutaka_Takeda@PlayStation.Sony.Com Wed Mar 9 12:39:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C523A6AB8 for ; Wed, 9 Mar 2011 12:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.053 X-Spam-Level: X-Spam-Status: No, score=-6.053 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWbHiz1WgUqZ for ; Wed, 9 Mar 2011 12:39:26 -0800 (PST) Received: from paris.playstation.sony.com (nat.playstation.sony.com [69.36.131.254]) by core3.amsl.com (Postfix) with ESMTP id 1D8233A6989 for ; Wed, 9 Mar 2011 12:39:24 -0800 (PST) Received: from constantine.playstation.sony.com ([162.49.67.15]) by paris.playstation.sony.com (Lotus Domino Release 8.5.1FP5) with ESMTP id 2011030912404119-249467 ; Wed, 9 Mar 2011 12:40:41 -0800 In-Reply-To: To: John Tamplin MIME-Version: 1.0 X-KeepSent: 71614916:EEE8DF65-8825784E:006CA753; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Yutaka_Takeda@PlayStation.Sony.Com Date: Wed, 9 Mar 2011 12:41:21 -0800 X-MIMETrack: Serialize by Router on SCEA919ML04/SCEA(Release 8.5.1FP3|May 23, 2010) at 03/09/2011 12:40:40 PM, Serialize complete at 03/09/2011 12:40:40 PM, Itemize by SMTP Server on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/09/2011 12:40:41 PM, Serialize by Router on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/09/2011 12:40:43 PM, Serialize complete at 03/09/2011 12:40:43 PM Content-Type: multipart/alternative; boundary="=_alternative 0071A6F48825784E_=" Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:39:28 -0000 This is a multipart message in MIME format. --=_alternative 0071A6F48825784E_= Content-Type: text/plain; charset="US-ASCII" hybi-bounces@ietf.org wrote on 03/09/2011 11:04:41 AM: > On Wed, Mar 9, 2011 at 1:41 PM, wrote: > Let me join in the voices for +1 on the use of reserved bit. > > I agree with your points of debate in the following messages: > - http://www.ietf.org/mail-archive/web/hybi/current/msg06631.html > - http://www.ietf.org/mail-archive/web/hybi/current/msg06633.html > > Reasons: > > o Sniffers can choose whether to go ahead and parse masked payload > based on the bit without having to capture from the start. > (It greatly helps us in debugging or trouble shooting) > > I agree this is useful, but I disagree that this is sufficient to > warrant the cost. > > o Ability to turn off masking for debugging/trouble shooting. > (this should not be manipulable by user code, of course, just to be clear) > > This is orthogonal to whether to use a bit in the frame, and from > previous discussions there is little support for being able to disable it. Right, I meant, to sniffers, the bit will tell whether the payload is masked in the midst of trasferring data while turning on/off on the fly for debugging purpose. > > o It is worthier allocating a bit for this than reserving it > for something we don't even know especially when we still have > at least a few bits left. > > The problem is there are only a few reserved bits, and we don't know > how many it would be useful to have. One thing that was discussed > earlier that would require allocation of a reserved bit would be > per-frame compression, so you can avoid compressing non-compressible > data. Another possibility is that we generally allocate more > opcodes for extensions, in which case we would like to be able to > allocate some of the reserved bits to the opcode field. We won't > know we used too many until we need more than we have, at which > point it becomes expensive (50% additional overhead for small > frames) to get more. When we came up with this framing, this was > the compromise between cost and leaving options open for the future > that everybody could live with. Obviously you have much clearer picture of possible usage of the reserved bits than I. I should respect your view/concern on this. > > Think about it from an efficiency point of view -- you are > suggesting allocating a bit in every frame that is going to be the > same for every frame in the same direction. How can that possibly > be good stewardship of limited resources, rather than specifying it > once in the header (or not at all if it is known to be set or clear > based on which side is initiating the connection)? We are already sending these reserved bits on the wire for nothing as of today, which is where I am coming from. (I understand, when we need to extend reserved bits field in the future, that's when the use of bit may be perceived as 'extra-bandwidth'.) > > o Lacking the bit seems to be the source of sense of asymmetry - > as in the frame not being self-descriptive for what's in the > payload (not to be confused by 'understanding' the payload), > seems to be a bad protocol design choice. > > The frame is already not self-descriptive -- if compression is > negotiated, you have to know that (plus the current compression > state) in order to interpret the frames. Likewise, other extensions > will likely modify interpretation of the payload. The compression is an extension and is optional, where making is a MUST in normal operations. We can always turn off compression, if needed during trouble shooting, then I am hoping to be able to dissect packets on the wire with unmasked data on the screen. Since WebSocket is long lived, it could be difficult to capture entire data with sniffer with finite amount of memory/disk space, and I am aware Wireshark really slows down when it captures large files for a long time. If we could selectively capture/dissect data, that would be very very helpful. > I still think it is not worth allocating a reserved bit to indicate > masking is present, but if most people want it I won't object too strenuously. I have been spending large portion of my time for debugging/trouble shooting, I may be too concerned about debuggability. I understand your points of arguments, though let me keep my +1 on the use of reserved bit for now. Thanks a lot for your comments. - Yutaka --=_alternative 0071A6F48825784E_= Content-Type: text/html; charset="US-ASCII"
hybi-bounces@ietf.org wrote on 03/09/2011 11:04:41 AM:

> On Wed, Mar 9, 2011 at 1:41 PM, <Yutaka_Takeda@playstation.sony.com> wrote:
> Let me join in the voices for +1 on the use of reserved bit.
>
> I agree with your points of debate in the following messages:
>  - http://www.ietf.org/mail-archive/web/hybi/current/msg06631.html
>  - http://www.ietf.org/mail-archive/web/hybi/current/msg06633.html
>
> Reasons:
>
>  o Sniffers can choose whether to go ahead and parse masked payload
>    based on the bit without having to capture from the start.
>    (It greatly helps us in debugging or trouble shooting)
>
> I agree this is useful, but I disagree that this is sufficient to
> warrant the cost.
>  
>  o Ability to turn off masking for debugging/trouble shooting.
>    (this should not be manipulable by user code, of course, just to be clear)
>
> This is orthogonal to whether to use a bit in the frame, and from
> previous discussions there is little support for being able to disable it.

Right, I meant, to sniffers, the bit will tell whether the payload is masked
in the midst of trasferring data while turning on/off on the fly for
debugging purpose.

>  
>  o It is worthier allocating a bit for this than reserving it
>    for something we don't even know especially when we still have
>    at least a few bits left.
>
> The problem is there are only a few reserved bits, and we don't know
> how many it would be useful to have.  One thing that was discussed
> earlier that would require allocation of a reserved bit would be
> per-frame compression, so you can avoid compressing non-compressible
> data.  Another possibility is that we generally allocate more
> opcodes for extensions, in which case we would like to be able to
> allocate some of the reserved bits to the opcode field.  We won't
> know we used too many until we need more than we have, at which
> point it becomes expensive (50% additional overhead for small
> frames) to get more.  When we came up with this framing, this was
> the compromise between cost and leaving options open for the future
> that everybody could live with.

Obviously you have much clearer picture of possible usage of the reserved
bits than I. I should respect your view/concern on this.

>  
> Think about it from an efficiency point of view -- you are
> suggesting allocating a bit in every frame that is going to be the
> same for every frame in the same direction.  How can that possibly
> be good stewardship of limited resources, rather than specifying it
> once in the header (or not at all if it is known to be set or clear
> based on which side is initiating the connection)?

We are already sending these reserved bits on the wire for nothing as
of today, which is where I am coming from. (I understand, when we
need to extend reserved bits field in the future, that's when the use
of bit may be perceived as 'extra-bandwidth'.)

>
>  o Lacking the bit seems to be the source of sense of asymmetry -
>    as in the frame not being self-descriptive for what's in the
>    payload (not to be confused by 'understanding' the payload),
>    seems to be a bad protocol design choice.
>  
> The frame is already not self-descriptive -- if compression is
> negotiated, you have to know that (plus the current compression
> state) in order to interpret the frames.  Likewise, other extensions
> will likely modify interpretation of the payload.

The compression is an extension and is optional, where making is a MUST
in normal operations. We can always turn off compression, if needed during
trouble shooting, then I am hoping to be able to dissect packets on
the wire with unmasked data on the screen. Since WebSocket is long
lived, it could be difficult to capture entire data with sniffer
with finite amount of memory/disk space, and I am aware Wireshark really
slows down when it captures large files for a long time. If we could
selectively capture/dissect data, that would be very very helpful.
> I still think it is not worth allocating a reserved bit to indicate
> masking is present, but if most people want it I won't object too strenuously.

I have been spending large portion of my time for debugging/trouble
shooting, I may be too concerned about debuggability. I understand your
points of arguments, though let me keep my +1 on the use of reserved
bit for now. Thanks a lot for your comments.


- Yutaka
--=_alternative 0071A6F48825784E_=-- From mcmanus@ducksong.com Wed Mar 9 13:07:35 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3EB13A6AB0 for ; Wed, 9 Mar 2011 13:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvQXYmqmNdSa for ; Wed, 9 Mar 2011 13:07:34 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 4BBB23A6A69 for ; Wed, 9 Mar 2011 13:07:34 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id 5C1751043E; Wed, 9 Mar 2011 16:08:50 -0500 (EST) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id D486310159; Wed, 9 Mar 2011 16:08:45 -0500 (EST) From: "Pat McManus @Mozilla" To: Greg Wilkins In-Reply-To: References: <4D77B885.5050109@callenish.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 09 Mar 2011 16:08:59 -0500 Message-ID: <1299704939.2606.238.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: Hybi , Yutaka_Takeda@playstation.sony.com Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:07:35 -0000 On Thu, 2011-03-10 at 07:33 +1100, Greg Wilkins wrote: > > So I think masking is a perfect exemplar for the use of a reserve bit. It is completely redundant information for any websocket implementation. as for wireshark - it gives one more input into a pile of heuristics that it already has to use given the lack of a binding between websockets and tcp frames. Frankly, I don't see what is so hard about guessing whether or not masking is in play without the bit - especially with the asymmetric framing. And no matter what you do, anything that has thrown away the TCP state will be flat out guessing anyhow. The trivial case is a websocket payload which is also valid websocket frame with the payload arranged at the start of the TCP packet payload. it's just one wasted bit. I don't really care that much. But I think -06 has it this all defined right. I think a much more persuasive argument for including a direction bit is binding some form of non reliable websockets over UDP or DCCP in the future. -- http://www.getfirefox.com/ From theturtle32@gmail.com Wed Mar 9 13:37:12 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277583A6AAB for ; Wed, 9 Mar 2011 13:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCurVXaa34Cl for ; Wed, 9 Mar 2011 13:37:11 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id E20483A6778 for ; Wed, 9 Mar 2011 13:37:10 -0800 (PST) Received: by iyj8 with SMTP id 8so1150656iyj.31 for ; Wed, 09 Mar 2011 13:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=fcsH+mILbJ4gdMvl2KzAgwLVmSjcVWkRtsFhF/08lbc=; b=m1xHtE0YJmZqUJOKcvBrJDH6cluPvKxZ6sovQUPWuk3C/uZOzwAbT5XJYm5JwZoZi4 ECRwrfhLdKYVTOEiPzbPqhluDw20PZ+Ba0dvT2njldy+a0rHn5xuIgcyZLEWdpcpnB8p beFKVHfE+ruaO28PJVIL5nV589blZCkTeYEqg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=C01LPQHTrjHJQ98FMmV11sfpnUa5cX6Wsek7+B5eN2q58LJmwU6uaPA/CpQ24qF7/u FhppOCd2g1yjLhHQR6uvpUIV4o5lGk73XCCQyLe30kPMBjcgOe8HHklMfEDCbZbT4qN9 ZEdy4PV9r9WBgnbauV+r0OI/V1XKttOsV9qmM= MIME-Version: 1.0 Received: by 10.42.18.71 with SMTP id w7mr2332630ica.308.1299706707722; Wed, 09 Mar 2011 13:38:27 -0800 (PST) Received: by 10.231.149.19 with HTTP; Wed, 9 Mar 2011 13:38:27 -0800 (PST) Date: Wed, 9 Mar 2011 13:38:27 -0800 Message-ID: From: Brian To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] Great work! X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:37:12 -0000 I just wanted to send a general "Thank you!" to everyone on the list for all your long-suffering hard work that has made WebSockets a great and yet still simple protocol. Last night I coded up a partial client implementation in Flash of the -06 draft... just enough to connect to Andy Green's excellent libwebsockets-test-server using the dumb-increment-protocol and receive the continually incrementing numbers that it spits out. I wrote an implementation of the handshake and a parser for the framing based on nothing but the current -06 draft, and to my surprise and delight, the whole thing worked perfectly on the first try. That is truly a testament to the quality of the draft and the clarity of its writing, as well as the simplicity of the protocol. It's extremely close to that perfect balance point of features vs. simplicity. So give yourselves all a collective pat on the back! We've really got an amazing working draft and an excellent protocol that is poised to truly transform the real-time web once it's complete! Actually sitting down to write my own implementation has really re-kindled my excitement and enthusiasm for the whole project! I plan to finish out the client implementation, with masking and support for extensions very soon. When it's in a more sane state I will publish it on GitHub, along with a pre-compiled Adobe Air test app that will work with all of Andy's libwebsockets-test-server subprotocols. Cheers, Brian From w@1wt.eu Wed Mar 9 13:41:01 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66EB3A6A79 for ; Wed, 9 Mar 2011 13:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9mHn4+btWCx for ; Wed, 9 Mar 2011 13:41:01 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 900E63A6778 for ; Wed, 9 Mar 2011 13:41:00 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p29LgC4G029538; Wed, 9 Mar 2011 22:42:12 +0100 Date: Wed, 9 Mar 2011 22:42:12 +0100 From: Willy Tarreau To: "Pat McManus @Mozilla" Message-ID: <20110309214212.GA29190@1wt.eu> References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1299704939.2606.238.camel@ds9.ducksong.com> User-Agent: Mutt/1.4.2.3i Cc: Hybi , Yutaka_Takeda@playstation.sony.com Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:41:01 -0000 On Wed, Mar 09, 2011 at 04:08:59PM -0500, Pat McManus @Mozilla wrote: > On Thu, 2011-03-10 at 07:33 +1100, Greg Wilkins wrote: > > > > > So I think masking is a perfect exemplar for the use of a reserve bit. > > It is completely redundant information for any websocket implementation. > > as for wireshark - it gives one more input into a pile of heuristics > that it already has to use given the lack of a binding between > websockets and tcp frames. Frankly, I don't see what is so hard about > guessing whether or not masking is in play without the bit - especially > with the asymmetric framing. > > And no matter what you do, anything that has thrown away the TCP state > will be flat out guessing anyhow. The trivial case is a websocket > payload which is also valid websocket frame with the payload arranged at > the start of the TCP packet payload. As someone playing all the day with network captures, I totally agree with you on this point. There is no relation between individually captured network packets and streamed contents if you don't have them from the start. Some framed protocols such as HTTP which have massive amounts of headers have their framings more easy to spot, but we managed to make something very cheap network-wise with WS and I suspect that the framing will be indiscernable from binary contents. However, I agree with most of Greg's pros/cons, especially with the one about the protocol design. Having a protocol whose upper layer changes the lower layer framing is really hard to extend, and having two versions of each decoding function in intermediaries is needlessly expensive to maintain. I'd be much more happy with a protocol where something in the framing or handshake indicates that the payload is masked and where the frames are transported in native form. I also like the analogy with HTTP BTW. It is possible (and common) to chunk-encode the transfer of gzipped-encoded contents. When doing so, the HTTP headers are clear-text, the transfer encoding is clear, and the gzipped contents are inserted in chunks. Fortunately we don't gzip the chunk size nor the header, nor do we chunk-encode the headers, otherwise it would become a terrible mess. So +1 from me for mask in the payload with an indication either in the handshake or using a reserved bit, but for considerations of protocol design and longterm extensivity, not just for basic asumptions about what a sniffer could decode in randomly captured packets. Regards, Willy From Yutaka_Takeda@PlayStation.Sony.Com Wed Mar 9 13:48:45 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1E93A6AB7 for ; Wed, 9 Mar 2011 13:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.059 X-Spam-Level: X-Spam-Status: No, score=-6.059 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRssk40Ztdy1 for ; Wed, 9 Mar 2011 13:48:43 -0800 (PST) Received: from paris.playstation.sony.com (nat.playstation.sony.com [69.36.131.254]) by core3.amsl.com (Postfix) with ESMTP id 926E03A6AB0 for ; Wed, 9 Mar 2011 13:48:43 -0800 (PST) Received: from constantine.playstation.sony.com ([162.49.67.15]) by paris.playstation.sony.com (Lotus Domino Release 8.5.1FP5) with ESMTP id 2011030913495915-252418 ; Wed, 9 Mar 2011 13:49:59 -0800 In-Reply-To: <4D778F5C.3020404@warmcat.com> To: Andy Green MIME-Version: 1.0 X-KeepSent: 4821AA00:120197B4-8825784E:0076F791; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Yutaka_Takeda@PlayStation.Sony.Com Date: Wed, 9 Mar 2011 13:51:28 -0800 X-MIMETrack: Serialize by Router on SCEA919ML04/SCEA(Release 8.5.1FP3|May 23, 2010) at 03/09/2011 01:49:58 PM, Serialize complete at 03/09/2011 01:49:58 PM, Itemize by SMTP Server on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/09/2011 01:49:59 PM, Serialize by Router on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 03/09/2011 01:50:01 PM, Serialize complete at 03/09/2011 01:50:01 PM Content-Type: multipart/alternative; boundary="=_alternative 007812508825784E_=" Cc: hybi@ietf.org Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:48:45 -0000 This is a multipart message in MIME format. --=_alternative 007812508825784E_= Content-Type: text/plain; charset="US-ASCII" > On 03/09/2011 02:02 PM, Somebody in the thread at some point said: > > Hi - > > > I'm still not sure if we're on the same table. Please allow me to > > explain my thoughts again. Sorry if i'm misunderstanding your point. > > > > Sending a close frame is not a problem. What I'm taking as a (small, > > OK. > > > but) problem is receiving a close frame. "Trailing bytes after Close > > frame" in Yutaka's post doesn't mean "any further packet" or "any other > > traffic going" on the WebSocket layer. It means trailing bytes generated > > by zlib. > > > > Your code luckily drained the "close, 3 bit header, 00 00 ff ff" which > > contains octets generated by zlib for performing Z_FULL_FLUSH. But > > please imagine someone split them into two TCP packets e.g. "close > > codes, 3 bit header" and "00 00 ff ff" and inserted some delay between > > OK. > > > them. Your callback is run with eff_buf.token filled with "... close > > codes, 3 bit header", and after that your callback is run again with > > eff_buf.token = "00 00 ff ff". > > OK I think I get your idea. So it is possible at the receiver I get > enough zlib codes in one packet that it emits the full close frame > decompressed from inflate(), and I go off and interpret that and try to > close the socket, but there is already some "dribble" from zlib in > flight in a second packet which never gets serviced then. > > The only thing is I set it to do Z_PARTIAL_FLUSH after every input is > added to the compressor. So it means the compressor cannot be holding > much of anything at the time we come and ask it to send the CLOSE frame > with Z_FULL_FLUSH. CLOSE frame is limited to 125 payload. So it seems > it would always issue one final compressed output buffer in this case, > including zlib trailer, which translates to one packet on the wire > reliably. I'm also using TCP_NODELAY to stop it aggregating packets and > causing latency. > > I agree it is a theoretical opportunity for something else to fragment > the packet and make the situation you're describing, but I can't see it > happening the thing is on a link with like 30-40 byte MTU which is what > is needed including TCP /IP headers to break the packet there. > > Are there other circumstances that can actually cause this I'm > overlooking too easily? Yes. Since your receive buffer passed in recv(2) has a predetermined finite size and you may not be reading all data in the kernel space (TCP) buffer. Depending on how it is implemented and timing, the receiver may successfully extract Close frame out of data you have just read from TCP socket, and then close the socket without bothering to read the outstanding data in the kernel. - Yutaka > Thanks for explaining your meaning to me. > > -Andy > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --=_alternative 007812508825784E_= Content-Type: text/html; charset="US-ASCII"

> On 03/09/2011 02:02 PM, Somebody in the thread at some point said:
>
> Hi -
>
> > I'm still not sure if we're on the same table. Please allow me to
> > explain my thoughts again. Sorry if i'm misunderstanding your point.
> >
> > Sending a close frame is not a problem. What I'm taking as a (small,
>
> OK.
>
> > but) problem is receiving a close frame. "Trailing bytes after Close
> > frame" in Yutaka's post doesn't mean "any further packet" or "any other
> > traffic going" on the WebSocket layer. It means trailing bytes generated
> > by zlib.
> >
> > Your code luckily drained the "close, 3 bit header, 00 00 ff ff" which
> > contains octets generated by zlib for performing Z_FULL_FLUSH. But
> > please imagine someone split them into two TCP packets e.g. "close
> > codes, 3 bit header" and "00 00 ff ff" and inserted some delay between
>
> OK.
>
> > them. Your callback is run with eff_buf.token filled with "... close
> > codes, 3 bit header", and after that your callback is run again with
> > eff_buf.token = "00 00 ff ff".
>
> OK I think I get your idea.  So it is possible at the receiver I get
> enough zlib codes in one packet that it emits the full close frame
> decompressed from inflate(), and I go off and interpret that and try to
> close the socket, but there is already some "dribble" from zlib in
> flight in a second packet which never gets serviced then.
>
> The only thing is I set it to do Z_PARTIAL_FLUSH after every input is
> added to the compressor.  So it means the compressor cannot be holding
> much of anything at the time we come and ask it to send the CLOSE frame
> with Z_FULL_FLUSH.  CLOSE frame is limited to 125 payload.  So it seems
> it would always issue one final compressed output buffer in this case,
> including zlib trailer, which translates to one packet on the wire
> reliably.  I'm also using TCP_NODELAY to stop it aggregating packets and
> causing latency.
>
> I agree it is a theoretical opportunity for something else to fragment
> the packet and make the situation you're describing, but I can't see it
> happening the thing is on a link with like 30-40 byte MTU which is what
> is needed including TCP /IP headers to break the packet there.
>
> Are there other circumstances that can actually cause this I'm
> overlooking too easily?

Yes. Since your receive buffer passed in recv(2) has a predetermined
finite size and you may not be reading all data in the kernel space
(TCP) buffer. Depending on how it is implemented and timing, the
receiver may successfully extract Close frame out of data you have just
read from TCP socket, and then close the socket without bothering to
read the outstanding data in the kernel.


- Yutaka


>  Thanks for explaining your meaning to me.
>
> -Andy
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
 --=_alternative 007812508825784E_=-- From andy.warmcat.com@googlemail.com Wed Mar 9 14:12:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC65D3A6AEB for ; Wed, 9 Mar 2011 14:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fS8w0IV45phs for ; Wed, 9 Mar 2011 14:12:12 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 39D393A6AE2 for ; Wed, 9 Mar 2011 14:12:12 -0800 (PST) Received: by wwa36 with SMTP id 36so857165wwa.13 for ; Wed, 09 Mar 2011 14:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=i/yiJXK/HJ1/2p79bB6L6F5TwYQmxdUc6b83aAFDzFY=; b=hIqwL0qacDjIqxJWbbP0jg6AiwencXOQGhFxUH6HhnsLQZnyLEHD8gTQXysZ8DmFGr YPoWT9rNm5Fe501VNtDRRfbtlBIQ6SbqmFx56D77SYS5M5LTqwYxDCsfVntDEnUgZmtn Oq/1eZn9zx62QN8TsuxzyI6td7JKZaWqpzong= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=bLe/H5V36bvbkeyIqf8UP8kj3Bvg5cP+jw4vOn8oJbLenvNnr5xfhrjV61Fgw5L8Yb O+iR4Ny/KobUP65TxC95UTLjA0DCe+ZD8ia4261DouG7XCZIYTZiai9dNCV5ARjfwt/j 1HT3nwBGPv+zAP3NiPpmGfwOisOBfwMA7qLiA= Received: by 10.227.139.89 with SMTP id d25mr698333wbu.58.1299708807836; Wed, 09 Mar 2011 14:13:27 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id o6sm1833760wbo.3.2011.03.09.14.13.25 (version=SSLv3 cipher=OTHER); Wed, 09 Mar 2011 14:13:26 -0800 (PST) Sender: Andy Green Message-ID: <4D77FB84.9010104@warmcat.com> Date: Wed, 09 Mar 2011 22:13:24 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: Yutaka_Takeda@PlayStation.Sony.Com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 22:12:14 -0000 On 03/09/2011 09:51 PM, Somebody in the thread at some point said: Hi - > > Are there other circumstances that can actually cause this I'm > > overlooking too easily? > > Yes. Since your receive buffer passed in recv(2) has a predetermined > finite size and you may not be reading all data in the kernel space > (TCP) buffer. Depending on how it is implemented and timing, the > receiver may successfully extract Close frame out of data you have just > read from TCP socket, and then close the socket without bothering to > read the outstanding data in the kernel. It's a good point. I can see how that's effectively fragmenting the thing entirely in userland at the receiver. However that seems simple to solve since the extra junk data is already received in kernel. Just before socket close time we just need to use a little poll() POLLIN loop with no timeout to drain it while there's stuff immediately pending, right? Nothing more will come and close is always happy. -Andy From ifette@google.com Wed Mar 9 21:21:16 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDE883A6870 for ; Wed, 9 Mar 2011 21:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.561 X-Spam-Level: X-Spam-Status: No, score=-105.561 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6evnSyTxu11 for ; Wed, 9 Mar 2011 21:21:14 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 3DB453A6816 for ; Wed, 9 Mar 2011 21:21:13 -0800 (PST) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p2A5MUuq009552 for ; Wed, 9 Mar 2011 21:22:30 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299734550; bh=vQr/NC6zgWnjS2CABgD0QX0HWrc=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=JQiY36EKjopoLQEzPaXE1uX05hH42jKWgoGwCR9vgDt/gZxojjh6OcT/cJHcmxYU7 DMImCjWiLLovcLccX1e3w== Received: from iyb26 (iyb26.prod.google.com [10.241.49.90]) by hpaq6.eem.corp.google.com with ESMTP id p2A5MSdr001954 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 9 Mar 2011 21:22:29 -0800 Received: by iyb26 with SMTP id 26so1282799iyb.6 for ; Wed, 09 Mar 2011 21:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=imaHXUJHTYGGMqdjqTtl+aHje4iC58eHmBrFhjWELBM=; b=Mk37TuWdv9QJSA9aPJmeZVAfW0ewTyRRSSLc6hPdUiCpR5hL6nIlDqtQr4qQ3Ba6OS ksQEpPrgjOT8xO6ph4oA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=Bm7xE7uQlK0EAGntbncOkgjYZwQczvvkH4s7QlUDk5aRVcItn7yUDUYijVhVQeYPRH SgN3y6h6TrK5y0PY7U2g== MIME-Version: 1.0 Received: by 10.43.55.83 with SMTP id vx19mr1949517icb.24.1299734547839; Wed, 09 Mar 2011 21:22:27 -0800 (PST) Received: by 10.231.34.131 with HTTP; Wed, 9 Mar 2011 21:22:27 -0800 (PST) In-Reply-To: <4D77FB84.9010104@warmcat.com> References: <4D77FB84.9010104@warmcat.com> Date: Wed, 9 Mar 2011 21:22:27 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Andy Green Content-Type: multipart/alternative; boundary=bcaec517a9ae06ba67049e1a0847 X-System-Of-Record: true Cc: hybi@ietf.org, Yutaka_Takeda@playstation.sony.com Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 05:21:16 -0000 --bcaec517a9ae06ba67049e1a0847 Content-Type: text/plain; charset=UTF-8 I'm going over the threads trying to figure out what i need to do, and I will admit that this one has me a bit stumped. If we adopt yoshino-san's proposal [1] to only compress the payload of the frame, does that put this issue to rest? [1] http://www.ietf.org/mail-archive/web/hybi/current/msg06674.html On Wed, Mar 9, 2011 at 2:13 PM, Andy Green wrote: > On 03/09/2011 09:51 PM, Somebody in the thread at some point said: > > Hi - > > > Are there other circumstances that can actually cause this I'm >> > overlooking too easily? >> >> Yes. Since your receive buffer passed in recv(2) has a predetermined >> finite size and you may not be reading all data in the kernel space >> (TCP) buffer. Depending on how it is implemented and timing, the >> receiver may successfully extract Close frame out of data you have just >> read from TCP socket, and then close the socket without bothering to >> read the outstanding data in the kernel. >> > > It's a good point. I can see how that's effectively fragmenting the thing > entirely in userland at the receiver. > > However that seems simple to solve since the extra junk data is already > received in kernel. Just before socket close time we just need to use a > little poll() POLLIN loop with no timeout to drain it while there's stuff > immediately pending, right? Nothing more will come and close is always > happy. > > > -Andy > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --bcaec517a9ae06ba67049e1a0847 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm going over the threads trying to figure out what i need to do, and = I will admit that this one has me a bit stumped. If we adopt yoshino-san= 9;s proposal [1] to only compress the payload of the frame, does that put t= his issue to rest?

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg06= 674.html

On Wed, Mar 9, 2011 at 2:13 = PM, Andy Green <an= dy@warmcat.com> wrote:
On 03/09/2011 09:51 PM, S= omebody in the thread at some point said:

Hi -

=C2=A0> Are there other circumstances that can actually cause this I'= ;m
=C2=A0> overlooking too easily?

Yes. Since your receive buffer passed in recv(2) has a predetermined
finite size and you may not be reading all data in the kernel space
(TCP) buffer. Depending on how it is implemented and timing, the
receiver may successfully extract Close frame out of data you have just
read from TCP socket, and then close the socket without bothering to
read the outstanding data in the kernel.

It's a good point. =C2=A0I can see how that's effectively fragmenti= ng the thing entirely in userland at the receiver.

However that seems simple to solve since the extra junk data is already rec= eived in kernel. =C2=A0Just before socket close time we just need to use a = little poll() POLLIN loop with no timeout to drain it while there's stu= ff immediately pending, right? =C2=A0Nothing more will come and close is al= ways happy.


-Andy
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--bcaec517a9ae06ba67049e1a0847-- From buskanaka@gmail.com Wed Mar 9 22:22:23 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28C5F3A68DA for ; Wed, 9 Mar 2011 22:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvgKbU9WEm-4 for ; Wed, 9 Mar 2011 22:22:20 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 707423A682D for ; Wed, 9 Mar 2011 22:22:20 -0800 (PST) Received: by eye13 with SMTP id 13so463249eye.31 for ; Wed, 09 Mar 2011 22:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=OtOXDykFxWbqdLK2iuHucXffkIesTLXrcd+o2Olh7k8=; b=nTaPsr8KVW3JMS0GfPZsWEM9SSpU37P70N7HiMJqUJDySsE7WrfJ1jiiQAy2ntNOD8 L7DXQKe+6qJ3j5NyHkjM3fyYrqRd8e4+WS43cef93Eg5UxMS6F7i/+kl551z4u2IjMY3 8hVvwA/8CSQGAW1DGFpFBGYKIbvXgya4Mx8Ss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=YIgHe0nSUqWjcy7PrRqwc1TFGofdkKvdA2feKM6PRocnSFK5OpISwbxLJah+v90EON r5g04pVEu1ic0H++V/dnxU2f4JszLr0AyJH+/s/0QUnaK9Rm3kE0QcAM2V7BQWQgvmPL ZSZth/KkiAYgCbbjjNWX9yDW7BTckwiM7U5Eo= Received: by 10.14.49.66 with SMTP id w42mr2475813eeb.17.1299738217062; Wed, 09 Mar 2011 22:23:37 -0800 (PST) MIME-Version: 1.0 Sender: buskanaka@gmail.com Received: by 10.14.119.136 with HTTP; Wed, 9 Mar 2011 22:23:17 -0800 (PST) In-Reply-To: References: From: Joel Martin Date: Thu, 10 Mar 2011 09:23:17 +0300 X-Google-Sender-Auth: kfzk1ShW1eORyx4Eb1HqPpizo14 Message-ID: To: Brian Content-Type: multipart/alternative; boundary=0023543a2adcbaa38b049e1ae2c8 Cc: Hybi Subject: Re: [hybi] Great work! X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 06:22:23 -0000 --0023543a2adcbaa38b049e1ae2c8 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 10, 2011 at 12:38 AM, Brian wrote: > Last night I coded up a partial client > implementation in Flash of the -06 draft... just enough to connect to > Andy Green's excellent libwebsockets-test-server using the > dumb-increment-protocol and receive the continually incrementing > numbers that it spits out. > > I plan to finish out the client implementation, with masking and > support for extensions very soon. When it's in a more sane state I > will publish it on GitHub, along with a pre-compiled Adobe Air test > app that will work with all of Andy's libwebsockets-test-server > subprotocols. > You might consider contributing to web-socket-js ( https://github.com/gimite/web-socket-js) which is a Flash implementation of the older 03 protocol. It is basically a drop in emulator for browsers without WebSockets (but that have Flash) and supports WSS (I added the SSL support to it a while ago). There are quite a few projects that already incorporate web-socket-js (Socket.IO, my own noVNC client, etc) so contributing to that would probably have more bang for the buck for everyone. If you or gimite don't implement 06/07 in web-socket-js then I will probably end up doing it but it might be a while before I get the chance to do so. Regards, Joel Martin (kanaka) --0023543a2adcbaa38b049e1ae2c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 10, 2011 at 12:38 AM, Brian <theturtle32@gma= il.com> wrote:
Last night I coded up a partial client
implementation in Flash of the -06 draft... just enough to connect to
Andy Green's excellent libwebsockets-test-server using the
dumb-increment-protocol and receive the continually incrementing
numbers that it spits out.

I plan to finish out the client implementation, with masking and
support for extensions very soon. =A0When it's in a more sane state I will publish it on GitHub, along with a pre-compiled Adobe Air test
app that will work with all of Andy's libwebsockets-test-server
subprotocols.

You might consider contri= buting to web-socket-js (https://github.com/gimite/web-socket-js) which is a Flash implementat= ion of the older 03 protocol. It is basically a drop in emulator for browse= rs without WebSockets (but that have Flash) and supports WSS (I added the S= SL support to it a while ago). There are quite a few projects that already = incorporate web-socket-js (Socket.IO, my own noVNC client, etc) so contribu= ting to that would probably have more bang for the buck for everyone. If yo= u or gimite don't implement 06/07 in web-socket-js then I will probably= end up doing it but it might be a while before I get the chance to do so.<= /div>

Regards,

Joel Martin (kanaka)<= /div>
--0023543a2adcbaa38b049e1ae2c8-- From buskanaka@gmail.com Wed Mar 9 22:27:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707B53A68DA for ; Wed, 9 Mar 2011 22:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKlicRIP-SSG for ; Wed, 9 Mar 2011 22:27:48 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 37CDC3A68C6 for ; Wed, 9 Mar 2011 22:27:47 -0800 (PST) Received: by eye13 with SMTP id 13so464354eye.31 for ; Wed, 09 Mar 2011 22:29:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:content-type; bh=7nO4QayBYIc57XlfLUNc2CJJEu7SaM7TAeGQX1CxhLc=; b=F8slfHTVj4V4cFK7L2jFiqm8/D5y2iMsH+bavBd2cjEKGUfiOpgHKJkVcaw6RGVlkE iX4xtD9Mf/B6noexg5I4E5lxgMVyZA0W7DzJOjmOINQb07YhcNivog+EKEbQf1DP+OXo 67TDNRk0pHHKDLYeq8h6kXBTYIVQl+gv2oCAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=KgZye130Nn0nScpM9f++ffE1Nc0tnrXEvzo1k/Vm2gsxnuR9a4dtcDgeYKmkZQlEjj d+1DK5qgwkqhBJDfZeqBg+o1zrcCssIILm1fkFWSCb52cjFXRvVKfKGmvNA7oLgLWZMm ft5sRkpmJr/+HGZXLewtBzqK88Q4rjnfE4nN0= Received: by 10.14.17.79 with SMTP id i55mr1850279eei.18.1299738544120; Wed, 09 Mar 2011 22:29:04 -0800 (PST) MIME-Version: 1.0 Sender: buskanaka@gmail.com Received: by 10.14.119.136 with HTTP; Wed, 9 Mar 2011 22:28:44 -0800 (PST) In-Reply-To: <20110309214212.GA29190@1wt.eu> References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> From: Joel Martin Date: Thu, 10 Mar 2011 09:28:44 +0300 X-Google-Sender-Auth: SvFJVQwKmwHBmrJZ4R7yr3KTE6Y Message-ID: To: Hybi Content-Type: multipart/alternative; boundary=0016e65a02543922f9049e1af638 Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 06:27:51 -0000 --0016e65a02543922f9049e1af638 Content-Type: text/plain; charset=ISO-8859-1 +1 for masking only payload/extension data. No opinion on whether to use an opcode bit or not for this. Joel Martin (kanaka) --0016e65a02543922f9049e1af638 Content-Type: text/html; charset=ISO-8859-1 +1 for masking only payload/extension data.

No opinion on whether to use an opcode bit or not for this.

Joel Martin (kanaka)
--0016e65a02543922f9049e1af638-- From salvatore.loreto@ericsson.com Wed Mar 9 22:57:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1C53A68C6 for ; Wed, 9 Mar 2011 22:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKgic7I9jAnm for ; Wed, 9 Mar 2011 22:57:49 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 288EE3A6808 for ; Wed, 9 Mar 2011 22:57:48 -0800 (PST) X-AuditID: c1b4fb39-b7c6dae0000023f2-ed-4d7876b96583 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 39.38.09202.9B6787D4; Thu, 10 Mar 2011 07:59:05 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Thu, 10 Mar 2011 07:59:04 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1F3DD2714; Thu, 10 Mar 2011 08:59:05 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CFB2E509C8; Thu, 10 Mar 2011 08:59:04 +0200 (EET) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6CF1B509A6; Thu, 10 Mar 2011 08:59:04 +0200 (EET) Message-ID: <4D7876B8.1010905@ericsson.com> Date: Thu, 10 Mar 2011 08:59:04 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ifette@google.com" References: <4D77FB84.9010104@warmcat.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070601090304090208060401" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" , "Yutaka_Takeda@playstation.sony.com" Subject: [hybi] change in 07: Payload only compression extension (was Re: With deflate-stream, Close frame doesn't work as an end of data marker) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 06:57:52 -0000 --------------070601090304090208060401 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit (as co-chair I want to bring your attention to this) Hi there, the following changes (proposed by Takeshi Yoshino in [1]) has been largely discussed (for the technical reasons follow the discussions thread [1] and [2]): the discussion has highlighted that the proposal brings some benefit and no side effects. [1] http://www.ietf.org/mail-archive/web/hybi/current/msg06642.html [2] http://www.ietf.org/mail-archive/web/hybi/current/msg06801.html [3] http://www.ietf.org/mail-archive/web/hybi/current/msg06674.html so unless anyone object strongly -07 will include the "yoshino-san's proposal" [3] cheers /Sal -- Salvatore Loreto www.sloreto.com On 3/10/11 7:22 AM, Ian Fette (イアンフェッティ) wrote: > I'm going over the threads trying to figure out what i need to do, and > I will admit that this one has me a bit stumped. If we adopt > yoshino-san's proposal [1] to only compress the payload of the frame, > does that put this issue to rest? > > [1] http://www.ietf.org/mail-archive/web/hybi/current/msg06674.html > > On Wed, Mar 9, 2011 at 2:13 PM, Andy Green > wrote: > > On 03/09/2011 09:51 PM, Somebody in the thread at some point said: > > Hi - > > > Are there other circumstances that can actually cause this I'm > > overlooking too easily? > > Yes. Since your receive buffer passed in recv(2) has a > predetermined > finite size and you may not be reading all data in the kernel > space > (TCP) buffer. Depending on how it is implemented and timing, the > receiver may successfully extract Close frame out of data you > have just > read from TCP socket, and then close the socket without > bothering to > read the outstanding data in the kernel. > > > It's a good point. I can see how that's effectively fragmenting > the thing entirely in userland at the receiver. > > However that seems simple to solve since the extra junk data is > already received in kernel. Just before socket close time we just > need to use a little poll() POLLIN loop with no timeout to drain > it while there's stuff immediately pending, right? Nothing more > will come and close is always happy. > > > -Andy > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --------------070601090304090208060401 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit (as co-chair I want to bring your attention to this)


Hi there,


the following changes (proposed by Takeshi Yoshino in [1])
has been largely discussed (for the technical reasons follow the discussions thread [1] and [2]):
the discussion has highlighted that the proposal brings some benefit and no side effects.



[1] http://www.ietf.org/mail-archive/web/hybi/current/msg06642.html
[2] http://www.ietf.org/mail-archive/web/hybi/current/msg06801.html
[3] http://www.ietf.org/mail-archive/web/hybi/current/msg06674.html


so unless anyone object strongly -07 will include the "yoshino-san's proposal" [3]


cheers
/Sal


-- 
Salvatore Loreto
www.sloreto.com


On 3/10/11 7:22 AM, Ian Fette (イアンフェッティ) wrote:
I'm going over the threads trying to figure out what i need to do, and I will admit that this one has me a bit stumped. If we adopt yoshino-san's proposal [1] to only compress the payload of the frame, does that put this issue to rest?

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg06674.html

On Wed, Mar 9, 2011 at 2:13 PM, Andy Green <andy@warmcat.com> wrote:
On 03/09/2011 09:51 PM, Somebody in the thread at some point said:

Hi -

 > Are there other circumstances that can actually cause this I'm
 > overlooking too easily?

Yes. Since your receive buffer passed in recv(2) has a predetermined
finite size and you may not be reading all data in the kernel space
(TCP) buffer. Depending on how it is implemented and timing, the
receiver may successfully extract Close frame out of data you have just
read from TCP socket, and then close the socket without bothering to
read the outstanding data in the kernel.

It's a good point.  I can see how that's effectively fragmenting the thing entirely in userland at the receiver.

However that seems simple to solve since the extra junk data is already received in kernel.  Just before socket close time we just need to use a little poll() POLLIN loop with no timeout to drain it while there's stuff immediately pending, right?  Nothing more will come and close is always happy.


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



--------------070601090304090208060401-- From ifette@google.com Wed Mar 9 22:59:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297B93A68DA for ; Wed, 9 Mar 2011 22:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.702 X-Spam-Level: X-Spam-Status: No, score=-105.702 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyQZDdyLvjCw for ; Wed, 9 Mar 2011 22:59:00 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 0D2E73A68BF for ; Wed, 9 Mar 2011 22:58:56 -0800 (PST) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p2A70DL8031015 for ; Wed, 9 Mar 2011 23:00:13 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299740413; bh=m/NBHXqyYDMr2NQS9h5SxzwAAiw=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=TldP/vAkBGxFqQUJRmRQwqsWPPbZ7JIQT8RYczprx/cjOF2iDXWi8qa00U3TZSEnM LW6pFO2tVJLy5ZAMJSiGw== Received: from iwn36 (iwn36.prod.google.com [10.241.68.100]) by hpaq5.eem.corp.google.com with ESMTP id p2A70ALa018541 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 9 Mar 2011 23:00:11 -0800 Received: by iwn36 with SMTP id 36so1404046iwn.36 for ; Wed, 09 Mar 2011 23:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=32XMP+cHPc7jc3uAEbLBUqeKS/qbH6Pe+afgQKCtj9A=; b=idxIjdGwYOPxifzxi+Jw5zlxgIHqwl2OAbfYASWfb9UxGErKgRVdk5kkFXkmFAXLZN EL7kjACJj6cxzDWf4vsA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=xyZrBcQ/FBeue2KEeYVKHiBkz1SRmcLn5SSvBvulRKTSufQgA6a4VuhnMg5RyokYMu y8v9eMkCBMHE20PeY5Ww== MIME-Version: 1.0 Received: by 10.231.146.18 with SMTP id f18mr5591605ibv.185.1299740410466; Wed, 09 Mar 2011 23:00:10 -0800 (PST) Received: by 10.231.34.131 with HTTP; Wed, 9 Mar 2011 23:00:10 -0800 (PST) In-Reply-To: <4D7876B8.1010905@ericsson.com> References: <4D77FB84.9010104@warmcat.com> <4D7876B8.1010905@ericsson.com> Date: Wed, 9 Mar 2011 23:00:10 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Salvatore Loreto Content-Type: multipart/alternative; boundary=0016e64afdc6775460049e1b65e2 X-System-Of-Record: true Cc: "hybi@ietf.org" , "Yutaka_Takeda@playstation.sony.com" Subject: Re: [hybi] change in 07: Payload only compression extension (was Re: With deflate-stream, Close frame doesn't work as an end of data marker) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 06:59:08 -0000 --0016e64afdc6775460049e1b65e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable seems straight forward enough. -ian On Wed, Mar 9, 2011 at 10:59 PM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > (as co-chair I want to bring your attention to this) > > > Hi there, > > > the following changes (proposed by Takeshi Yoshino in [1]) > has been largely discussed (for the technical reasons follow the > discussions thread [1] and [2]): > the discussion has highlighted that the proposal brings some benefit and = no > side effects. > > > > [1] http://www.ietf.org/mail-archive/web/hybi/current/msg06642.html > [2] http://www.ietf.org/mail-archive/web/hybi/current/msg06801.html > [3] http://www.ietf.org/mail-archive/web/hybi/current/msg06674.html > > > so unless anyone object strongly -07 will include the "yoshino-san's > proposal" [3] > > > cheers > /Sal > > > -- > Salvatore Loretowww.sloreto.com > > > > On 3/10/11 7:22 AM, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82= =A7=E3=83=83=E3=83=86=E3=82=A3) wrote: > > I'm going over the threads trying to figure out what i need to do, and I > will admit that this one has me a bit stumped. If we adopt yoshino-san's > proposal [1] to only compress the payload of the frame, does that put thi= s > issue to rest? > > [1] http://www.ietf.org/mail-archive/web/hybi/current/msg06674.html > > On Wed, Mar 9, 2011 at 2:13 PM, Andy Green wrote: > >> On 03/09/2011 09:51 PM, Somebody in the thread at some point said: >> >> Hi - >> >> > Are there other circumstances that can actually cause this I'm >>> > overlooking too easily? >>> >>> Yes. Since your receive buffer passed in recv(2) has a predetermined >>> finite size and you may not be reading all data in the kernel space >>> (TCP) buffer. Depending on how it is implemented and timing, the >>> receiver may successfully extract Close frame out of data you have just >>> read from TCP socket, and then close the socket without bothering to >>> read the outstanding data in the kernel. >>> >> >> It's a good point. I can see how that's effectively fragmenting the >> thing entirely in userland at the receiver. >> >> However that seems simple to solve since the extra junk data is already >> received in kernel. Just before socket close time we just need to use a >> little poll() POLLIN loop with no timeout to drain it while there's stuf= f >> immediately pending, right? Nothing more will come and close is always >> happy. >> >> >> -Andy >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> > > > > --0016e64afdc6775460049e1b65e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable seems straight forward enough.

-ian

On Wed, Mar 9, 2011 at 10:59 PM, Salvatore Loreto <salvatore.lor= eto@ericsson.com> wrote:
=20 =20 =20
(as co-chair I want to bring your attention to this)


Hi there,


the following changes (proposed by Takeshi Yoshino in [1])
has been largely discussed (for the technical reasons follow the discussions thread [1] and [2]):
the discussion has highlighted that the proposal brings some benefit and no side effects.



[1] http://www.ietf.org/mail-archive/web/hybi/curren= t/msg06642.html
[2] http://www.ietf.org/mail-archive/web/hybi/curren= t/msg06801.html
[3] http://www.ietf.org/mail-archive/web/hybi/curren= t/msg06674.html


so unless anyone object strongly -07 will include the "yoshino-san= 's proposal" [3]


cheers
/Sal


--=20
Salvatore Loreto
www.sloreto.com
    

    

    On 3/10/11 7:22 AM, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=
=82=A7=E3=83=83=E3=83=86=E3=82=A3) wrote:
    
I'm going over the threads trying to figu=
re out what i
      need to do, and I will admit that this one has me a bit stumped.
      If we adopt yoshino-san's proposal [1] to only compress the
      payload of the frame, does that put this issue to rest?
      

        

      

      
[1] http://www.ietf.org/mail-archive/web/hybi=
/current/msg06674.html

        

        
On Wed, Mar 9, 2011 at 2:13 PM, Andy
          Green <andy@warmcat.com>
          wrote:

          

            
On 03/09/2011 09:51 PM, Somebody in the
              thread at some point said:

              

              Hi -

              

            

            

              

                =C2=A0> Are there other circumstances that can actually
                cause this I'm

                =C2=A0> overlooking too easily?

                

                Yes. Since your receive buffer passed in recv(2) has a
                predetermined

                finite size and you may not be reading all data in the
                kernel space

                (TCP) buffer. Depending on how it is implemented and
                timing, the

                receiver may successfully extract Close frame out of
                data you have just

                read from TCP socket, and then close the socket without
                bothering to

                read the outstanding data in the kernel.

              

              

            

            It's a good point. =C2=A0I can see how that's effective=
ly
            fragmenting the thing entirely in userland at the receiver.

            

            However that seems simple to solve since the extra junk data
            is already received in kernel. =C2=A0Just before socket close
            time we just need to use a little poll() POLLIN loop with no
            timeout to drain it while there's stuff immediately pending=
,
            right? =C2=A0Nothing more will come and close is always happy.
            

              


                

                -Andy

                _______________________________________________

                hybi mailing list

                hybi@iet=
f.org

                https://www.ietf.org/mailman/listinfo/hybi

--0016e64afdc6775460049e1b65e2-- From theturtle32@gmail.com Wed Mar 9 23:20:30 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D433A6808 for ; Wed, 9 Mar 2011 23:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJkxdKbG1T02 for ; Wed, 9 Mar 2011 23:20:29 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id CDB9D3A683C for ; Wed, 9 Mar 2011 23:20:29 -0800 (PST) Received: by iyj8 with SMTP id 8so1587015iyj.31 for ; Wed, 09 Mar 2011 23:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c1RiAH6A9/CBz6TrQgQWKqr+Pi9aI0AC4SV1jXAF6u4=; b=ROe1F0j8X7spWiJDkY8Y+fjKXBlk8uuOKzuu6TwGBmmRfUn5TVQ5QaGYihAxFWlb1a qvRpFAgCAt7MIKNX2owK/H4HYfro6sUoaSRpzZMzQ9Y89BUfdvMWY5vFGmpzc/03p2VF 3O7Oyp2DgIz1DTq1waQ9Tp3/Ws6uvbG9b1CmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TKOHE+D0QszHoMHmXmYfbjJ+GyZ53fV1QtES6oCEAwzU+6rPgeOJ+H+DbyUk/Hj+K+ 66HOx/XVxELftxM+8AWblu4s3yE9QFVoFuYDHEmEwTe9M/sUF+l6FLpYdO7VKs9A85nF CxZpH6NViN9HxxyBuOsY/FMRm0C2WIGv2Rg4A= MIME-Version: 1.0 Received: by 10.43.45.67 with SMTP id uj3mr9417889icb.442.1299741707070; Wed, 09 Mar 2011 23:21:47 -0800 (PST) Received: by 10.231.149.19 with HTTP; Wed, 9 Mar 2011 23:21:47 -0800 (PST) In-Reply-To: <4D7876B8.1010905@ericsson.com> References: <4D77FB84.9010104@warmcat.com> <4D7876B8.1010905@ericsson.com> Date: Wed, 9 Mar 2011 23:21:47 -0800 Message-ID: From: Brian To: Salvatore Loreto Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "Yutaka_Takeda@playstation.sony.com" , "hybi@ietf.org" Subject: Re: [hybi] change in 07: Payload only compression extension (was Re: With deflate-stream, Close frame doesn't work as an end of data marker) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 07:20:30 -0000 Sounds fantastic! Brian On Wed, Mar 9, 2011 at 10:59 PM, Salvatore Loreto wrote: > (as co-chair I want to bring your attention to this) > > > Hi there, > > > the following changes (proposed by Takeshi Yoshino in [1]) > has been largely discussed (for the technical reasons follow the discussions > thread [1] and [2]): > the discussion has highlighted that the proposal brings some benefit and no > side effects. > > > > [1] http://www.ietf.org/mail-archive/web/hybi/current/msg06642.html > [2] http://www.ietf.org/mail-archive/web/hybi/current/msg06801.html > [3] http://www.ietf.org/mail-archive/web/hybi/current/msg06674.html > > > so unless anyone object strongly -07 will include the "yoshino-san's > proposal" [3] > > > cheers > /Sal > > > -- > Salvatore Loreto > www.sloreto.com > > On 3/10/11 7:22 AM, Ian Fette ($B%$%"%s%U%'%C%F%#(B) wrote: > > I'm going over the threads trying to figure out what i need to do, and I > will admit that this one has me a bit stumped. If we adopt yoshino-san's > proposal [1] to only compress the payload of the frame, does that put this > issue to rest? > [1] http://www.ietf.org/mail-archive/web/hybi/current/msg06674.html > > On Wed, Mar 9, 2011 at 2:13 PM, Andy Green wrote: >> >> On 03/09/2011 09:51 PM, Somebody in the thread at some point said: >> >> Hi - >> >>> > Are there other circumstances that can actually cause this I'm >>> > overlooking too easily? >>> >>> Yes. Since your receive buffer passed in recv(2) has a predetermined >>> finite size and you may not be reading all data in the kernel space >>> (TCP) buffer. Depending on how it is implemented and timing, the >>> receiver may successfully extract Close frame out of data you have just >>> read from TCP socket, and then close the socket without bothering to >>> read the outstanding data in the kernel. >> >> It's a good point. I can see how that's effectively fragmenting the thing >> entirely in userland at the receiver. >> >> However that seems simple to solve since the extra junk data is already >> received in kernel. Just before socket close time we just need to use a >> little poll() POLLIN loop with no timeout to drain it while there's stuff >> immediately pending, right? Nothing more will come and close is always >> happy. >> >> -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 > > From ietf@adambarth.com Thu Mar 10 00:38:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0FE3A6886 for ; Thu, 10 Mar 2011 00:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbwzplBfkcOR for ; Thu, 10 Mar 2011 00:38:24 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id F2EF43A683B for ; Thu, 10 Mar 2011 00:38:23 -0800 (PST) Received: by yxk30 with SMTP id 30so749195yxk.31 for ; Thu, 10 Mar 2011 00:39:41 -0800 (PST) Received: by 10.150.147.5 with SMTP id u5mr694945ybd.307.1299746381127; Thu, 10 Mar 2011 00:39:41 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id v15sm2111349ybk.18.2011.03.10.00.39.38 (version=SSLv3 cipher=OTHER); Thu, 10 Mar 2011 00:39:39 -0800 (PST) Received: by iyj8 with SMTP id 8so1651930iyj.31 for ; Thu, 10 Mar 2011 00:39:38 -0800 (PST) Received: by 10.42.221.71 with SMTP id ib7mr2669396icb.110.1299746378133; Thu, 10 Mar 2011 00:39:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.10.200 with HTTP; Thu, 10 Mar 2011 00:39:08 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> From: Adam Barth Date: Thu, 10 Mar 2011 00:39:08 -0800 Message-ID: To: Joel Martin Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 08:38:24 -0000 -1 for masking only payload/extension data. It's less secure, and that's not acceptable. Adam On Wed, Mar 9, 2011 at 10:28 PM, Joel Martin wrote: > +1 for masking only payload/extension data. > No opinion on whether to use an opcode bit or not for this. > Joel Martin (kanaka) > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > From andy.warmcat.com@googlemail.com Thu Mar 10 00:47:31 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4583A6841 for ; Thu, 10 Mar 2011 00:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rzAvijBKLta for ; Thu, 10 Mar 2011 00:47:30 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id D68F03A6817 for ; Thu, 10 Mar 2011 00:47:29 -0800 (PST) Received: by wwa36 with SMTP id 36so1163236wwa.13 for ; Thu, 10 Mar 2011 00:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zONh/uEiOuZ/IOOMJc7d/PNTM1JqBupyXAZshE6ifGA=; b=DUTY5Iwv6pgtTCl+Q+24k1rD8RyXqtp8X2Hv/R5crFuYrdsdukcAck+73kYIjCDPQ5 R/0q7NfT1CCnCFdf+Bw5k2TWg0XqB1V9QMTtJNZQewI+r9kEdlFoQueLP/qx36zov7yu /bilJjp1d8YtYbtPO5UZdA/pUX7mAXFETQ3NQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=L3b6R3kfiNSexbyPb5de33xgYFvnW0zoFRw24t4Sw8jd741ME5cGCjVyYV8oJIGdMn a6QHnWVEA0lc9VpbZVoRXgEkRirIOw+YHex3Rc6xVhCFfwvneeOQHiPCwVJDGKlsm4cJ ufwLL3p/6FyEv+6tsMky57R/kcanrkupK4vVM= Received: by 10.227.202.139 with SMTP id fe11mr2675156wbb.169.1299746926626; Thu, 10 Mar 2011 00:48:46 -0800 (PST) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id y29sm2221686wbd.22.2011.03.10.00.48.43 (version=SSLv3 cipher=OTHER); Thu, 10 Mar 2011 00:48:44 -0800 (PST) Sender: Andy Green Message-ID: <4D78906A.7040005@warmcat.com> Date: Thu, 10 Mar 2011 08:48:42 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: Adam Barth References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 08:47:31 -0000 On 03/10/2011 08:39 AM, Somebody in the thread at some point said: > -1 for masking only payload/extension data. It's less secure, and > that's not acceptable. Since this is the second time you asserted it's "not wise" and "less secure" and now "not acceptable" with no explanation, do you think you could take us through your reasoning? -Andy From andy.warmcat.com@googlemail.com Thu Mar 10 00:54:52 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777183A687E for ; Thu, 10 Mar 2011 00:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.626 X-Spam-Level: X-Spam-Status: No, score=-3.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrEUcxsa0OpO for ; Thu, 10 Mar 2011 00:54:51 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 493303A68BA for ; Thu, 10 Mar 2011 00:54:51 -0800 (PST) Received: by wwi17 with SMTP id 17so1172807wwi.1 for ; Thu, 10 Mar 2011 00:56:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sSa5xqMdf9IJDI0RreKK/6Wp4VVZZk12r8HHSe5BLdc=; b=Q55wUa1RFatVWNt4355mAyfDhIHkDc8RrrCGjKsAttkkYsyCnjG7P0d2+XoZztdn3U T0duFAyg7TpqTQ6gpslPUFbp14y0GtpijHqyx39JyQF2jNfpkBArXneqCaHUHRERzDDM zS2gHUHGudQm1NcBfoVfIBGL9RKZXX4SfbTZ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=eQ/MXEEuzK2GWr3i+qZERbofMwg5/0eQknr1Ukw210oxxELU5JQ//JXpyE75wEQvC5 YLu71CVQkiYVX9gpDbC7K6FVma/wGAy+/pscZLa0sbnhRIRpC6UPKk+ykRvhk6BC96TR XJeseV+iaRlT8jrin41OemMYHEZRMzDD6m198= Received: by 10.227.195.76 with SMTP id eb12mr760888wbb.160.1299747366322; Thu, 10 Mar 2011 00:56:06 -0800 (PST) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id x1sm543770wbh.2.2011.03.10.00.56.04 (version=SSLv3 cipher=OTHER); Thu, 10 Mar 2011 00:56:04 -0800 (PST) Sender: Andy Green Message-ID: <4D789223.8010208@warmcat.com> Date: Thu, 10 Mar 2011 08:56:03 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: ifette@google.com References: <4D77FB84.9010104@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, Yutaka_Takeda@playstation.sony.com Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 08:54:52 -0000 On 03/10/2011 05:22 AM, Somebody in the thread at some point said: Hi - > I'm going over the threads trying to figure out what i need to do, and I > will admit that this one has me a bit stumped. If we adopt yoshino-san's > proposal [1] to only compress the payload of the frame, does that put > this issue to rest? > > [1] http://www.ietf.org/mail-archive/web/hybi/current/msg06674.html Payload only compression would be nice. However this "dribbling compression codes after close" thing is not a problem in the real world that I can see and at most maybe needs a note that before closing a socket compressed like this, you may need to drain it in a loop polling it with no timeout and POLLIN until nothing is left before calling close(). Also one note on Yoshino's language to describe the compression actions it mixes Z_ nomenclature that zlib uses and hex packets on the wire, if this hex trailer that he mentions is a byproduct of Z_FINISH or whatever it might be clearer to an implementer that he can generate it like that and forget mentioning magic hex. -Andy From ietf@adambarth.com Thu Mar 10 01:07:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A9CF3A689A for ; Thu, 10 Mar 2011 01:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyb2ELPk1+2A for ; Thu, 10 Mar 2011 01:07:27 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 2DAB53A6857 for ; Thu, 10 Mar 2011 01:07:27 -0800 (PST) Received: by gwb20 with SMTP id 20so431810gwb.31 for ; Thu, 10 Mar 2011 01:08:44 -0800 (PST) Received: by 10.147.165.3 with SMTP id s3mr7877566yao.6.1299748124319; Thu, 10 Mar 2011 01:08:44 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id 35sm259579ano.31.2011.03.10.01.08.42 (version=SSLv3 cipher=OTHER); Thu, 10 Mar 2011 01:08:43 -0800 (PST) Received: by iyj8 with SMTP id 8so1677280iyj.31 for ; Thu, 10 Mar 2011 01:08:42 -0800 (PST) Received: by 10.231.113.96 with SMTP id z32mr5686105ibp.191.1299748122120; Thu, 10 Mar 2011 01:08:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.10.200 with HTTP; Thu, 10 Mar 2011 01:08:12 -0800 (PST) In-Reply-To: <4D78906A.7040005@warmcat.com> References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D78906A.7040005@warmcat.com> From: Adam Barth Date: Thu, 10 Mar 2011 01:08:12 -0800 Message-ID: To: Andy Green Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 09:07:28 -0000 On Thu, Mar 10, 2011 at 12:48 AM, Andy Green wrote: > On 03/10/2011 08:39 AM, Somebody in the thread at some point said: >> -1 for masking only payload/extension data. =A0It's less secure, and >> that's not acceptable. > > Since this is the second time you asserted it's "not wise" and "less secu= re" > and now "not acceptable" with no explanation, do you think you could take= us > through your reasoning? I was tired of repeating my explanation the last time we had this thread: http://www.ietf.org/mail-archive/web/hybi/current/msg06630.html As far as I can tell, no one has provided any additional information. We can have these threads until the cows come home, but if no one is adding any information, they're a waste of time. Adam From andy.warmcat.com@googlemail.com Thu Mar 10 01:31:31 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31A73A6893 for ; Thu, 10 Mar 2011 01:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.625 X-Spam-Level: X-Spam-Status: No, score=-3.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n5fmkCRCI9l for ; Thu, 10 Mar 2011 01:31:28 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 56BC13A67EF for ; Thu, 10 Mar 2011 01:31:28 -0800 (PST) Received: by wyb42 with SMTP id 42so1440693wyb.31 for ; Thu, 10 Mar 2011 01:32:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1zUyQefGuQ2dPhMbcdLm48mzOu23dh2MS17LAM0EpbE=; b=q0iILLTeMIJPNrSFg5Iu2eO/NIIOqB4GyTiqltlqgphhupaZJ3ZSmMSgO8AS7VJwm6 3Pr35hqroxcGZo5otrBE/F+KbbfMZ9HxfGiWpHAjCWOMvwcRB1XyXFtOQDMLeRV/WyS+ kyewLduxS7lO89ujAsPCUlB5xBn/BxXHpDiWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=w0YkavGusDV4YrF+9NIdxk8TxSxwVJLk0o/C1E/DlSSUwjlQ5quJ9B/EwWEGHcKTYI e+a7eqKrRSbc4Ehq/hU2yoxKnqL8TcYkGjN4JtbxOxvZWsN28qnOaPIC9i5BowvD7OBW YjjZfYyVMpl/4l4MudA0rEebiAto+tk1z0TZI= Received: by 10.227.93.36 with SMTP id t36mr6778087wbm.11.1299749564994; Thu, 10 Mar 2011 01:32:44 -0800 (PST) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id o6sm2252068wbo.21.2011.03.10.01.32.42 (version=SSLv3 cipher=OTHER); Thu, 10 Mar 2011 01:32:43 -0800 (PST) Sender: Andy Green Message-ID: <4D789AB9.6050402@warmcat.com> Date: Thu, 10 Mar 2011 09:32:41 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: Adam Barth References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D78906A.7040005@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 09:31:31 -0000 On 03/10/2011 09:08 AM, Somebody in the thread at some point said: > On Thu, Mar 10, 2011 at 12:48 AM, Andy Green wrote: >> On 03/10/2011 08:39 AM, Somebody in the thread at some point said: >>> -1 for masking only payload/extension data. It's less secure, and >>> that's not acceptable. >> >> Since this is the second time you asserted it's "not wise" and "less secure" >> and now "not acceptable" with no explanation, do you think you could take us >> through your reasoning? > > I was tired of repeating my explanation the last time we had this thread: > > http://www.ietf.org/mail-archive/web/hybi/current/msg06630.html You have linked to the email where you simply tell us masking inside the framing is "not wise", you didn't participate in the rest of the thread, or add to or challenge Greg's list of pluses and minuses. > As far as I can tell, no one has provided any additional information. > We can have these threads until the cows come home, but if no one is > adding any information, they're a waste of time. You have not added any information to this thread either. I think if you're going to set off bombs like "not wise", "less secure" and "not acceptable" you need to at least qualify them with what exactly it's less secure against and why, who can't accept it under what criteria. Maybe what you think it is less secure against doesn't matter when it is analysed. Things that you or I individually "can't accept" still may be good for the protocol. Otherwise, it sounds pretty indistinguishable from handwaving. How it feels to me is your one-sentence sniping is a threat to reignite a security taint on the protocol if you don't get listened to. I would like to improve my opinion of what you're trying to achieve by interjecting, but when asked for an explanation so I can try to understand if the issue is real or not you are "too tired" again. -Andy From theturtle32@gmail.com Thu Mar 10 02:24:12 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3CC53A67F8 for ; Thu, 10 Mar 2011 02:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4eNlRV4h9Gd for ; Thu, 10 Mar 2011 02:24:12 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D278D3A67F1 for ; Thu, 10 Mar 2011 02:24:11 -0800 (PST) Received: by iwl42 with SMTP id 42so1764055iwl.31 for ; Thu, 10 Mar 2011 02:25:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=x2CQFFhV/jZawOTVvsr/LxGpj9opGMNYKtDKM8M4DYg=; b=WxSyt8YP2Un9uZwmbABNGM297VOM8QAyG/LJl6mO+2y5UOqkgprtuamX+TZXW0wIHv LlkIodErwlMKwlGLN1IZjCf5baJ/MUzQAmG/aYsfgfCXHLY7OM9sBnwL0vMSTxTy+5mz awTO65jZfW6mawB5bUD8yj20PKZanIkui4RGo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=VFO2iMlO0Nz1B3H+sg0LCUwSVHMo4DY7J9WL7SHcIaf+7zlUHjrRVjV1QOnp/2TYZh a/GrBrskO8RYfnl15Du1F3O7z+hSrqe6wXKZO/FpbexfmYrsjGGrDS4UahxpapJg4e7u OKPs+wZoLbNuOKvfaynqWkMOkjC6x7soM7szI= MIME-Version: 1.0 Received: by 10.42.18.71 with SMTP id w7mr3166922ica.308.1299752729060; Thu, 10 Mar 2011 02:25:29 -0800 (PST) Received: by 10.231.149.19 with HTTP; Thu, 10 Mar 2011 02:25:28 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> Date: Thu, 10 Mar 2011 02:25:28 -0800 Message-ID: From: Brian To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 10:24:12 -0000 By my count, we have six voices in favor so far, including myself: Andy Green Ytaka Takeda Greg Wilkins Willy Tarreau Joel Martin Brian McKelvey One on record as not having a strong opinion one way or the other: Ian Fette And one opposed: Adam Barth Adam's curt and patronizing reply is once again unenlightening as to any viable reason why we need to mask the frame header as well as the payload, beyond just his gut feeling on the matter. I'd like to re-assert that since the only field under a potential hacker's control is the length (and potentially rsv bits via undefined extensions in the future) that the practical possibility of the frame header being used for an attack that actually accomplishes anything is so remote it's utterly laughable. Adam, if you really want to block this proposal, please respond with an actual analysis and a potential exploit case that's compelling enough to reverse the momentum built behind this proposal. Brian On Thu, Mar 10, 2011 at 12:39 AM, Adam Barth wrote: > -1 for masking only payload/extension data. =A0It's less secure, and > that's not acceptable. > > Adam > > > On Wed, Mar 9, 2011 at 10:28 PM, Joel Martin wrote= : >> +1 for masking only payload/extension data. >> No opinion on whether to use an opcode bit or not for this. >> Joel Martin (kanaka) >> _______________________________________________ >> 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 > From w@1wt.eu Thu Mar 10 02:38:07 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F6E3A68B5 for ; Thu, 10 Mar 2011 02:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bbt36ttorOq6 for ; Thu, 10 Mar 2011 02:38:03 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id EBCEC3A68D7 for ; Thu, 10 Mar 2011 02:38:02 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p2AAdEET000597; Thu, 10 Mar 2011 11:39:14 +0100 Date: Thu, 10 Mar 2011 11:39:14 +0100 From: Willy Tarreau To: Brian Message-ID: <20110310103914.GA32389@1wt.eu> References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 10:38:07 -0000 On Thu, Mar 10, 2011 at 02:25:28AM -0800, Brian wrote: > By my count, we have six voices in favor so far, including myself: > Andy Green > Ytaka Takeda > Greg Wilkins > Willy Tarreau > Joel Martin > Brian McKelvey > > One on record as not having a strong opinion one way or the other: > Ian Fette > > And one opposed: > Adam Barth > > > Adam's curt and patronizing reply is once again unenlightening as to > any viable reason why we need to mask the frame header as well as the > payload, beyond just his gut feeling on the matter. I'd like to > re-assert that since the only field under a potential hacker's control > is the length (and potentially rsv bits via undefined extensions in > the future) that the practical possibility of the frame header being > used for an attack that actually accomplishes anything is so remote > it's utterly laughable. I'd like to add that it's important to remember that this controllable length is not even at the beginning of the frame, and that there are uncontrollable bytes before. Regards, Willy From buskanaka@gmail.com Thu Mar 10 03:04:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81A4F3A68F3 for ; Thu, 10 Mar 2011 03:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 850w2ORlM165 for ; Thu, 10 Mar 2011 03:04:57 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id F0A563A68ED for ; Thu, 10 Mar 2011 03:04:54 -0800 (PST) Received: by ewy19 with SMTP id 19so563299ewy.31 for ; Thu, 10 Mar 2011 03:06:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:content-type; bh=SfXe8ktoNSwOjDljS/erojlfkurnrPc2osVbL8YSGbY=; b=mQb6xI6n48aFTTBs4l6LorNTglNKeDpJ5eDbThvyELLYmQifZE0c3Nkt+susSa6MJ9 COYskJHATWYnVUusC5fjfKVfIwFBPddu6W2hNg+SmOk9RX8CvQoRUulTtqQaEM/AnlIi j/RMCU+KPL+5nzz8t0AY7mmW/q2rJF1sOFyNM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=dj1AoJ+3RiUpyXG22byAyymwS2aiWWpExpuFv3RALHXQzF4IUkTZkTqiPeWyPS6vBB 58/PPt75MRzI/iEc6W73sUj0jE5+695FfT6vmMjkCIDkhvrpUMBDZHByEtlFlhX+useD XHnlrDabrozq3kybwAz/vxgsJFGRxMssUBeV8= Received: by 10.14.13.194 with SMTP id b42mr4348512eeb.31.1299755172108; Thu, 10 Mar 2011 03:06:12 -0800 (PST) MIME-Version: 1.0 Sender: buskanaka@gmail.com Received: by 10.14.119.136 with HTTP; Thu, 10 Mar 2011 03:05:52 -0800 (PST) In-Reply-To: <20110310103914.GA32389@1wt.eu> References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <20110310103914.GA32389@1wt.eu> From: Joel Martin Date: Thu, 10 Mar 2011 14:05:52 +0300 X-Google-Sender-Auth: 8UIVySyiMhx4EaQyIgI5qxfXZWQ Message-ID: To: Hybi Content-Type: multipart/alternative; boundary=0016e65bb696541c88049e1ed558 Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 11:04:58 -0000 --0016e65bb696541c88049e1ed558 Content-Type: text/plain; charset=ISO-8859-1 I've been following this discussion pretty closely and I'm willing to change my mind if Adam (or somebody else) can clearly lay out a threat model that isn't easily addressed by minor tweaking. I really am interested in what real threat may exist and not just being stubborn. Please enlighten me. As somebody else has proposed, the allowable range of values in the length field can always be reduced in the future by fragmenting to avoid _specific_ known vulnerable intermediaries (in the implementations without even changing the protocol). I.e. if "GET\n" is a problem, then client implementations can just never send that value. I suspect most would agree that masking of everything is better than stalling the protocol any longer, but if Adam is the only objector and the browser folks are okay with masking only payload then perhaps we should move forward with it. Joel Martin (kanaka) On Thu, Mar 10, 2011 at 1:39 PM, Willy Tarreau wrote: > On Thu, Mar 10, 2011 at 02:25:28AM -0800, Brian wrote: > > By my count, we have six voices in favor so far, including myself: > > Andy Green > > Ytaka Takeda > > Greg Wilkins > > Willy Tarreau > > Joel Martin > > Brian McKelvey > > > > One on record as not having a strong opinion one way or the other: > > Ian Fette > > > > And one opposed: > > Adam Barth > > > > > > Adam's curt and patronizing reply is once again unenlightening as to > > any viable reason why we need to mask the frame header as well as the > > payload, beyond just his gut feeling on the matter. I'd like to > > re-assert that since the only field under a potential hacker's control > > is the length (and potentially rsv bits via undefined extensions in > > the future) that the practical possibility of the frame header being > > used for an attack that actually accomplishes anything is so remote > > it's utterly laughable. > > I'd like to add that it's important to remember that this controllable > length is not even at the beginning of the frame, and that there are > uncontrollable bytes before. > > Regards, > Willy > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --0016e65bb696541c88049e1ed558 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've been following this discussion pretty closely and I'm willing = to change my mind if Adam (or somebody else) can clearly lay out a threat m= odel that isn't easily addressed by minor tweaking. I really am interes= ted in what real threat may exist and not just being stubborn. Please enlig= hten me.

As somebody else has proposed, the allowable range of values= in the length field can always be reduced in the future by fragmenting to = avoid _specific_ known vulnerable intermediaries (in the implementations wi= thout even changing the protocol). I.e. if "GET\n" is a problem, = then client implementations can just never send that value.

I suspect most would agree that masking of everything is bet= ter than stalling the protocol any longer, but if Adam is the only objector= and the browser folks are okay with masking only payload then perhaps we s= hould move forward with it.

Joel Martin (kanaka)

On Thu, Mar 10, 2011 at 1:39 PM, Willy Tarreau <= ;w@1wt.eu> wrote:
On Thu, Mar 10, 2011 at 02:25:28AM -0800, Brian wrote: > By my count, we have six voices in favor so far, including myself:
> Andy Green
> Ytaka Takeda
> Greg Wilkins
> Willy Tarreau
> Joel Martin
> Brian McKelvey
>
> One on record as not having a strong opinion one way or the other:
> Ian Fette
>
> And one opposed:
> Adam Barth
>
>
> Adam's curt and patronizing reply is once again unenlightening as = to
> any viable reason why we need to mask the frame header as well as the<= br> > payload, beyond just his gut feeling on the matter. =A0I'd like to=
> re-assert that since the only field under a potential hacker's con= trol
> is the length (and potentially rsv bits via undefined extensions in > the future) that the practical possibility of the frame header being > used for an attack that actually accomplishes anything is so remote > it's utterly laughable.

I'd like to add that it's important to remember that this con= trollable
length is not even at the beginning of the frame, and that there are
uncontrollable bytes before.

Regards,
Willy

_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--0016e65bb696541c88049e1ed558-- From ietf@adambarth.com Thu Mar 10 03:30:01 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76BA73A6921 for ; Thu, 10 Mar 2011 03:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.807 X-Spam-Level: X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSxyx3LSeIgF for ; Thu, 10 Mar 2011 03:30:00 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 2F83F3A690F for ; Thu, 10 Mar 2011 03:30:00 -0800 (PST) Received: by yxk30 with SMTP id 30so813489yxk.31 for ; Thu, 10 Mar 2011 03:31:17 -0800 (PST) Received: by 10.236.191.3 with SMTP id f3mr1082835yhn.143.1299756677536; Thu, 10 Mar 2011 03:31:17 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id k29sm2048724yhk.14.2011.03.10.03.31.15 (version=SSLv3 cipher=OTHER); Thu, 10 Mar 2011 03:31:16 -0800 (PST) Received: by iyj8 with SMTP id 8so1805809iyj.31 for ; Thu, 10 Mar 2011 03:31:15 -0800 (PST) Received: by 10.42.159.201 with SMTP id m9mr8551696icx.244.1299756675064; Thu, 10 Mar 2011 03:31:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.10.200 with HTTP; Thu, 10 Mar 2011 03:30:45 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <20110310103914.GA32389@1wt.eu> From: Adam Barth Date: Thu, 10 Mar 2011 03:30:45 -0800 Message-ID: To: Joel Martin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 11:30:01 -0000 Thanks for having an open mind Joel. Let's start with some basic assumptio= ns: 1) Attacks only get better over time. Over the (hopefully) many years folks will be using this protocol, the attacks we know about today will continue to exist, and security researchers will continue to learn more techniques and improve their attacks. That means we should design protocols with a margin of safety rather than pushing up against the razor edge of what we can reliably exploit today. Admitted, this aspect of security is somewhat of an art, and at some point we'll need to defer to the judgement of security experts as to how much of a margin we need for safety. 2) If an attacker can choose a moderately long sequence of bytes of the wire, we lose. More specifically, we can construct attacks today that abuse certain configurations of proxies using a moderate length of chosen bytes. Because of (1), we should expect the length of these sequences and the amount of damage attacker can cause with them to increase over time. The story would be different if we had some solid reasoning about lower bounds on length or upper bounds on damage, but we don't. For simplicity, let's consider the base framing protocol: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06#section-= 4.3 Let's assume we're only going to mask the extension data and the application data. That leds approximately 10 bytes at the beginning of the frame that's unmasked. Are these bytes under the control of the attacker? In large part, they are. For example, the attacker is relatively free to select the payload length. The attacker is also likely to have a large amount of control over the opcode (recall that the attacker can drive the protocol state machine into relatively arbitrary states). As for the various reserved bits, we don't know very much about how these bits will be used, but if they're likely to be at least partially under the influence of the attacker. Worse, consider the case where the attacker sends a sequence of very short (e.g., zero or one byte) messages. Now the attacker can control (or can strongly influence) an appreciable fraction of the bytes on the wire. Additionally, the attacker gets feedback (i.e., by seeing the bytes that arrive at the server) and can dynamically adjust subsequent messages based on this feedback. So, does the above add up to an attack I can demonstrate today? No. Is there reasonable evidence that attackers will be able to stich together the above weaknesses to construct an attack in the future? Yes. Given what we know today, my view is that not masking the entire frame is an unacceptable level of risk. Adam On Thu, Mar 10, 2011 at 3:05 AM, Joel Martin wrote: > I've been following this discussion pretty closely and I'm willing to cha= nge > my mind if Adam (or somebody else) can clearly lay out a threat model tha= t > isn't easily addressed by minor tweaking. I really am interested in what > real threat may exist and not just being stubborn. Please enlighten me. > As somebody else has proposed, the allowable range of values in the lengt= h > field can always be reduced in the future by fragmenting to avoid _specif= ic_ > known vulnerable intermediaries (in the implementations without even > changing the protocol). I.e. if "GET\n" is a problem, then client > implementations can just never send that value. > I suspect most would agree that masking of everything is better than > stalling the protocol any longer, but if Adam is the only objector and th= e > browser folks are okay with masking only payload then perhaps we should m= ove > forward with it. > Joel Martin (kanaka) > On Thu, Mar 10, 2011 at 1:39 PM, Willy Tarreau wrote: >> >> On Thu, Mar 10, 2011 at 02:25:28AM -0800, Brian wrote: >> > By my count, we have six voices in favor so far, including myself: >> > Andy Green >> > Ytaka Takeda >> > Greg Wilkins >> > Willy Tarreau >> > Joel Martin >> > Brian McKelvey >> > >> > One on record as not having a strong opinion one way or the other: >> > Ian Fette >> > >> > And one opposed: >> > Adam Barth >> > >> > >> > Adam's curt and patronizing reply is once again unenlightening as to >> > any viable reason why we need to mask the frame header as well as the >> > payload, beyond just his gut feeling on the matter. =A0I'd like to >> > re-assert that since the only field under a potential hacker's control >> > is the length (and potentially rsv bits via undefined extensions in >> > the future) that the practical possibility of the frame header being >> > used for an attack that actually accomplishes anything is so remote >> > it's utterly laughable. >> >> I'd like to add that it's important to remember that this controllable >> length is not even at the beginning of the frame, and that there are >> uncontrollable bytes before. >> >> Regards, >> Willy >> >> _______________________________________________ >> 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 > > From jamie@shareable.org Thu Mar 10 03:50:16 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8523A6926 for ; Thu, 10 Mar 2011 03:50:16 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7HLyIMKLim9 for ; Thu, 10 Mar 2011 03:50:15 -0800 (PST) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 4735B3A681A for ; Thu, 10 Mar 2011 03:50:12 -0800 (PST) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1PxeOl-0001qO-4k; Thu, 10 Mar 2011 11:51:19 +0000 Date: Thu, 10 Mar 2011 11:51:19 +0000 From: Jamie Lokier To: Andy Green Message-ID: <20110310115119.GI29234@shareable.org> References: <4D775D69.8010808@warmcat.com> <4D777402.3010101@warmcat.com> <4D778F5C.3020404@warmcat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D778F5C.3020404@warmcat.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: hybi@ietf.org, Yutaka_Takeda@playstation.sony.com Subject: [hybi] TCP packet boundaries must not be assumed (was Re: With deflate-stream, Close frame doesn't work as an end of data marker) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 11:50:16 -0000 Andy Green wrote: > with Z_FULL_FLUSH. CLOSE frame is limited to 125 payload. So it seems > it would always issue one final compressed output buffer in this case, > including zlib trailer, which translates to one packet on the wire > reliably. I'm also using TCP_NODELAY to stop it aggregating packets and > causing latency. You *cannot* depend on such a write translating to one output packet. You also cannot depend on TCP_NODELAY preventing packet aggregation. There are many corner cases, but here is a few simple ones: When there is any bottleneck such as congestion, receiver too slow, receiver busy or not enough bandwidth somewhere, the sender will delay sending, or resend, and so may aggregate more data into previously queued packets. This is an area where I have had to hit programmers over the head with a cluebrick, when their program that "worked fine on our LAN" would occasionally, rarely, drop connections when run over other networks or even when run on different OSes with different TCP implementations. It is a nightmare to debug and fix protocols that make that assumption. TCP can, and occasionally does, split and join the byte stream at arbitrary positions. It should always by treated as doing so. It is ok to optimise with awareness of packet boundaries, but not to depend on it for reliability. Even if your sending host does not, various tunnels, proxies, relays, transcoders etc. in the middle may alter the packet splitting. In TCP, write() does not reliably correspond to packets, and neither does read(). When orderly close (close-message) is used to avoid TCP reset hazard, it is important for the receiver to defer close() or shutdown(SHUT_RD) until it knows it has _definitely_ read the _last byte_ from the socket. The last byte may be split off and delayed by flow control history, and when it finally arrives, if close or SHUT_RD is done too soon, the last byte causes a TCP reset, breaking unfinished messages in the other direction. This isn't about "reading OS buffers"; it can also be data in flight. So you can't solve this by exhaustively reading from the socket before closing. Apache handles this by waiting for TCP FIN, but WebSocket can't depend on that. -- Jamie From ifette@google.com Thu Mar 10 03:51:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC313A681A for ; Thu, 10 Mar 2011 03:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrI+JJMCJRLo for ; Thu, 10 Mar 2011 03:51:25 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B70583A692F for ; Thu, 10 Mar 2011 03:51:24 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p2ABqfJU004957 for ; Thu, 10 Mar 2011 03:52:42 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299757962; bh=C/7ixe/w+qzEB7nh5hlAAubSpJ0=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=q/tZ1N/vebTsgcOjP8C9i53c/B0bFkU/3A3V47T5PTNVCkpBoTUdDAP/2l+Q6raiL z8vnwlYuu+O7Lny8JLyRQ== Received: from iyb12 (iyb12.prod.google.com [10.241.49.76]) by wpaz24.hot.corp.google.com with ESMTP id p2ABqaQU027954 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 10 Mar 2011 03:52:40 -0800 Received: by iyb12 with SMTP id 12so1582186iyb.29 for ; Thu, 10 Mar 2011 03:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=L6UME+sHkuaect4wYYPpwhM4IOJNhC6aSw7RgAWqk+o=; b=dQtGFCfYsly4FerTS0W1XUCrkjZEXQ9HVj4fxAihEZtomp+tnyWjTaQEMmVIn8j2q3 Brb7sIQz0PHQfCP7BDkw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=qdSJIq85ht7DgnXq55/DZn9wevf7bFE5g5FqROd7ByrDqkad9RXvTODtclc9KRbUzZ Tvtrd1fIKu7r9jiQfR1Q== MIME-Version: 1.0 Received: by 10.43.46.9 with SMTP id um9mr10021897icb.158.1299757960679; Thu, 10 Mar 2011 03:52:40 -0800 (PST) Received: by 10.231.34.131 with HTTP; Thu, 10 Mar 2011 03:52:40 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <20110310103914.GA32389@1wt.eu> Date: Thu, 10 Mar 2011 03:52:40 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Adam Barth Content-Type: multipart/alternative; boundary=bcaec52997438a4f8d049e1f7b18 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 11:51:26 -0000 --bcaec52997438a4f8d049e1f7b18 Content-Type: text/plain; charset=UTF-8 The attacker is relatively free to select the length of the message, but that may or may not translate into the length of a given frame. For instance, a browser may decide to fragment a large message. Looking at the base framing, the attacker can also choose between a text and binary frame. In practice, I would be surprised if the attacker had control over more than seventeen bits coming from a browser. We (the browser at its discretion) could also choose to e.g. fragment a message if it saw a length equal to "GET\n" or "POST" or any number of such keywords, though I admit that it is no sure fire defense against potential attacks. At the end of the day, I think you are right in saying that it does open up additional attack surface and potential. The question is how plausible do we believe such an attack to be, what is the potential damage, and what do we gain in exchange? The handshake in theory means that we're looking at attacks against ill-formed proxies as the primary attack target/vector. We can argue about whether these are likely to grow in number or shrink in number, but at the end of the day it is a relatively small number of endpoints that are already exploitable via other means as you demonstrated. I am willing to live with masking, but at some point I do think we need to look at it as a cost benefit analysis, and not be willing to afford infinite cost to the "proxies may get exploited" line of reasoning. I don't mean to dismiss the issue by any means, but merely to say that there is a limit to how much we should accomodate these things. -Ian (hopefully that's a sufficiently cryptic response to maintain my previously stated neutral stance) On Thu, Mar 10, 2011 at 3:30 AM, Adam Barth wrote: > Thanks for having an open mind Joel. Let's start with some basic > assumptions: > > 1) Attacks only get better over time. Over the (hopefully) many years > folks will be using this protocol, the attacks we know about today > will continue to exist, and security researchers will continue to > learn more techniques and improve their attacks. That means we should > design protocols with a margin of safety rather than pushing up > against the razor edge of what we can reliably exploit today. > Admitted, this aspect of security is somewhat of an art, and at some > point we'll need to defer to the judgement of security experts as to > how much of a margin we need for safety. > > 2) If an attacker can choose a moderately long sequence of bytes of > the wire, we lose. More specifically, we can construct attacks today > that abuse certain configurations of proxies using a moderate length > of chosen bytes. Because of (1), we should expect the length of these > sequences and the amount of damage attacker can cause with them to > increase over time. The story would be different if we had some solid > reasoning about lower bounds on length or upper bounds on damage, but > we don't. > > For simplicity, let's consider the base framing protocol: > > > http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06#section-4.3 > > Let's assume we're only going to mask the extension data and the > application data. That leds approximately 10 bytes at the beginning > of the frame that's unmasked. Are these bytes under the control of > the attacker? In large part, they are. For example, the attacker is > relatively free to select the payload length. The attacker is also > likely to have a large amount of control over the opcode (recall that > the attacker can drive the protocol state machine into relatively > arbitrary states). As for the various reserved bits, we don't know > very much about how these bits will be used, but if they're likely to > be at least partially under the influence of the attacker. > > Worse, consider the case where the attacker sends a sequence of very > short (e.g., zero or one byte) messages. Now the attacker can control > (or can strongly influence) an appreciable fraction of the bytes on > the wire. Additionally, the attacker gets feedback (i.e., by seeing > the bytes that arrive at the server) and can dynamically adjust > subsequent messages based on this feedback. > > So, does the above add up to an attack I can demonstrate today? No. > Is there reasonable evidence that attackers will be able to stich > together the above weaknesses to construct an attack in the future? > Yes. Given what we know today, my view is that not masking the entire > frame is an unacceptable level of risk. > > Adam > > > On Thu, Mar 10, 2011 at 3:05 AM, Joel Martin wrote: > > I've been following this discussion pretty closely and I'm willing to > change > > my mind if Adam (or somebody else) can clearly lay out a threat model > that > > isn't easily addressed by minor tweaking. I really am interested in what > > real threat may exist and not just being stubborn. Please enlighten me. > > As somebody else has proposed, the allowable range of values in the > length > > field can always be reduced in the future by fragmenting to avoid > _specific_ > > known vulnerable intermediaries (in the implementations without even > > changing the protocol). I.e. if "GET\n" is a problem, then client > > implementations can just never send that value. > > I suspect most would agree that masking of everything is better than > > stalling the protocol any longer, but if Adam is the only objector and > the > > browser folks are okay with masking only payload then perhaps we should > move > > forward with it. > > Joel Martin (kanaka) > > On Thu, Mar 10, 2011 at 1:39 PM, Willy Tarreau wrote: > >> > >> On Thu, Mar 10, 2011 at 02:25:28AM -0800, Brian wrote: > >> > By my count, we have six voices in favor so far, including myself: > >> > Andy Green > >> > Ytaka Takeda > >> > Greg Wilkins > >> > Willy Tarreau > >> > Joel Martin > >> > Brian McKelvey > >> > > >> > One on record as not having a strong opinion one way or the other: > >> > Ian Fette > >> > > >> > And one opposed: > >> > Adam Barth > >> > > >> > > >> > Adam's curt and patronizing reply is once again unenlightening as to > >> > any viable reason why we need to mask the frame header as well as the > >> > payload, beyond just his gut feeling on the matter. I'd like to > >> > re-assert that since the only field under a potential hacker's control > >> > is the length (and potentially rsv bits via undefined extensions in > >> > the future) that the practical possibility of the frame header being > >> > used for an attack that actually accomplishes anything is so remote > >> > it's utterly laughable. > >> > >> I'd like to add that it's important to remember that this controllable > >> length is not even at the beginning of the frame, and that there are > >> uncontrollable bytes before. > >> > >> Regards, > >> Willy > >> > >> _______________________________________________ > >> 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 > > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --bcaec52997438a4f8d049e1f7b18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The attacker is relatively free to select the length of the message, but th= at may or may not translate into the length of a given frame. For instance,= a browser may decide to fragment a large message. Looking at the base fram= ing, the attacker can also choose between a text and binary frame. In pract= ice, I would be surprised if the attacker had control over more than sevent= een bits coming from a browser. We (the browser at its discretion) could al= so choose to e.g. fragment a message if it saw a length equal to "GET\= n" or "POST" or any number of such keywords, though I admit = that it is no sure fire defense against potential attacks.=C2=A0

At the end of the day, I think you are right in saying that = it does open up additional attack surface and potential. The question is ho= w plausible do we believe such an attack to be, what is the potential damag= e, and what do we gain in exchange? The handshake in theory means that we&#= 39;re looking at attacks against ill-formed proxies as the primary attack t= arget/vector. We can argue about whether these are likely to grow in number= or shrink in number, but at the end of the day it is a relatively small nu= mber of endpoints that are already exploitable via other means as you demon= strated. I am willing to live with masking, but at some point I do think we= need to look at it as a cost benefit analysis, and not be willing to affor= d infinite cost to the "proxies may get exploited" line of reason= ing. I don't mean to dismiss the issue by any means, but merely to say = that there is a limit to how much we should accomodate these things.

-Ian (hopefully that's a sufficiently cryptic respo= nse to maintain my previously stated neutral stance)

On Thu, Mar 10, 2011 at 3:30 AM, Adam Barth <ietf@adambarth.com><= /span> wrote:
Thanks for having an open mind Joel. =C2=A0= Let's start with some basic assumptions:

1) Attacks only get better over time. =C2=A0Over the (hopefully) many years=
folks will be using this protocol, the attacks we know about today
will continue to exist, and security researchers will continue to
learn more techniques and improve their attacks. =C2=A0That means we should=
design protocols with a margin of safety rather than pushing up
against the razor edge of what we can reliably exploit today.
Admitted, this aspect of security is somewhat of an art, and at some
point we'll need to defer to the judgement of security experts as to how much of a margin we need for safety.

2) If an attacker can choose a moderately long sequence of bytes of
the wire, we lose. =C2=A0More specifically, we can construct attacks today<= br> that abuse certain configurations of proxies using a moderate length
of chosen bytes. =C2=A0Because of (1), we should expect the length of these=
sequences and the amount of damage attacker can cause with them to
increase over time. =C2=A0The story would be different if we had some solid=
reasoning about lower bounds on length or upper bounds on damage, but
we don't.

For simplicity, let's consider the base framing protocol:

http://tools.ietf.org/html/draft-ietf-hyb= i-thewebsocketprotocol-06#section-4.3

Let's assume we're only going to mask the extension data and the application data. =C2=A0That leds approximately 10 bytes at the beginning of the frame that's unmasked. =C2=A0Are these bytes under the control o= f
the attacker? =C2=A0In large part, they are. =C2=A0For example, the attacke= r is
relatively free to select the payload length. =C2=A0The attacker is also likely to have a large amount of control over the opcode (recall that
the attacker can drive the protocol state machine into relatively
arbitrary states). =C2=A0As for the various reserved bits, we don't kno= w
very much about how these bits will be used, but if they're likely to be at least partially under the influence of the attacker.

Worse, consider the case where the attacker sends a sequence of very
short (e.g., zero or one byte) messages. =C2=A0Now the attacker can control=
(or can strongly influence) an appreciable fraction of the bytes on
the wire. =C2=A0Additionally, the attacker gets feedback (i.e., by seeing the bytes that arrive at the server) and can dynamically adjust
subsequent messages based on this feedback.

So, does the above add up to an attack I can demonstrate today? =C2=A0No. Is there reasonable evidence that attackers will be able to stich
together the above weaknesses to construct an attack in the future?
Yes. =C2=A0Given what we know today, my view is that not masking the entire=
frame is an unacceptable level of risk.

Adam


On Thu, Mar 10, 2011 at 3:05 AM, Joel Martin <hybi@martintribe.org> wrote:
> I've been following this discussion pretty closely and I'm wil= ling to change
> my mind if Adam (or somebody else) can clearly lay out a threat model = that
> isn't easily addressed by minor tweaking. I really am interested i= n what
> real threat may exist and not just being stubborn. Please enlighten me= .
> As somebody else has proposed, the allowable range of values in the le= ngth
> field can always be reduced in the future by fragmenting to avoid _spe= cific_
> known vulnerable intermediaries (in the implementations without even > changing the protocol). I.e. if "GET\n" is a problem, then c= lient
> implementations can just never send that value.
> I suspect most would agree that masking of everything is better than > stalling the protocol any longer, but if Adam is the only objector and= the
> browser folks are okay with masking only payload then perhaps we shoul= d move
> forward with it.
> Joel Martin (kanaka)
> On Thu, Mar 10, 2011 at 1:39 PM, Willy Tarreau <w@1wt.eu> wrote:
>>
>> On Thu, Mar 10, 2011 at 02:25:28AM -0800, Brian wrote:
>> > By my count, we have six voices in favor so far, including my= self:
>> > Andy Green
>> > Ytaka Takeda
>> > Greg Wilkins
>> > Willy Tarreau
>> > Joel Martin
>> > Brian McKelvey
>> >
>> > One on record as not having a strong opinion one way or the o= ther:
>> > Ian Fette
>> >
>> > And one opposed:
>> > Adam Barth
>> >
>> >
>> > Adam's curt and patronizing reply is once again unenlight= ening as to
>> > any viable reason why we need to mask the frame header as wel= l as the
>> > payload, beyond just his gut feeling on the matter. =C2=A0I&#= 39;d like to
>> > re-assert that since the only field under a potential hacker&= #39;s control
>> > is the length (and potentially rsv bits via undefined extensi= ons in
>> > the future) that the practical possibility of the frame heade= r being
>> > used for an attack that actually accomplishes anything is so = remote
>> > it's utterly laughable.
>>
>> I'd like to add that it's important to remember that this = controllable
>> length is not even at the beginning of the frame, and that there a= re
>> uncontrollable bytes before.
>>
>> Regards,
>> Willy
>>
>> _______________________________________________
>> 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
>
>
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--bcaec52997438a4f8d049e1f7b18-- From ifette@google.com Thu Mar 10 04:00:56 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DDB73A6A4E for ; Thu, 10 Mar 2011 04:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.697 X-Spam-Level: X-Spam-Status: No, score=-105.697 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sra8SXiUJRSo for ; Thu, 10 Mar 2011 04:00:54 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 14BB03A6A1E for ; Thu, 10 Mar 2011 04:00:53 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p2AC2BOS032126 for ; Thu, 10 Mar 2011 04:02:11 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299758531; bh=CXV8ipKF+s2xqkO13FZPcrZ3/DY=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=kwVnX97RCcKXBKXzgB2tUmR0JF0Za/WpkmkuFd4tyALmDZm4S7q4L+bHms5ekdcem pb4YFwf12QMwvoUYEtRpA== Received: from iwn3 (iwn3.prod.google.com [10.241.68.67]) by wpaz21.hot.corp.google.com with ESMTP id p2AC29Xg005096 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 10 Mar 2011 04:02:10 -0800 Received: by iwn3 with SMTP id 3so2970586iwn.1 for ; Thu, 10 Mar 2011 04:02:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UVAg/K2cezQeuTrKDuyZmmRwgkGeDWXroLikO5Rt3pM=; b=ynJwFvM5a8T9o0OVvzQ3Efz+wyswa7XBSUJSfSRJJbom1B3i5Uc3N/dI1J5/EM9bX+ Rxqd4AS/akfbKFtLlQdQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=kwU5HIr6uRNRONNJLAPrC5suQoeONzxBo2fK3Ukrzy1TT2xz5qW+iLDSLbiWoYLjoV jbDdSFua0buFLkRZnCDA== MIME-Version: 1.0 Received: by 10.231.165.141 with SMTP id i13mr5787093iby.135.1299758529547; Thu, 10 Mar 2011 04:02:09 -0800 (PST) Received: by 10.231.34.131 with HTTP; Thu, 10 Mar 2011 04:02:09 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <20110310103914.GA32389@1wt.eu> Date: Thu, 10 Mar 2011 04:02:09 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Adam Barth Content-Type: multipart/alternative; boundary=0003255736e6728f49049e1f9d26 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 12:00:56 -0000 --0003255736e6728f49049e1f9d26 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That said, looking at the wiki again, I am not really sure I understand the benefits that intermediaries would get from this. Either way it looks like they need to be able to pick out frame boundaries, and to do that reliably = I think they have to read frame header 1, see how long that frame is, and basically skip that many bytes to get to frame 2. I don't understand how they could do it without parsing the frame header for frame 1. The masking doesn't make it that difficult to get to the frame header, you have to xor on the order of 10 bytes. A lot of the complexity savings seem predicated o= n the thought that we may choose a different, stream-based masking algorithm, which I thought we already decided against because of some of those exact issues? Again, I'm not against it, but I don't really see enough benefit to say I'm for it either. -Ian 2011/3/10 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83= =E3=83=86=E3=82=A3) > The attacker is relatively free to select the length of the message, but > that may or may not translate into the length of a given frame. For > instance, a browser may decide to fragment a large message. Looking at th= e > base framing, the attacker can also choose between a text and binary fram= e. > In practice, I would be surprised if the attacker had control over more t= han > seventeen bits coming from a browser. We (the browser at its discretion) > could also choose to e.g. fragment a message if it saw a length equal to > "GET\n" or "POST" or any number of such keywords, though I admit that it = is > no sure fire defense against potential attacks. > > At the end of the day, I think you are right in saying that it does open = up > additional attack surface and potential. The question is how plausible do= we > believe such an attack to be, what is the potential damage, and what do w= e > gain in exchange? The handshake in theory means that we're looking at > attacks against ill-formed proxies as the primary attack target/vector. W= e > can argue about whether these are likely to grow in number or shrink in > number, but at the end of the day it is a relatively small number of > endpoints that are already exploitable via other means as you demonstrate= d. > I am willing to live with masking, but at some point I do think we need t= o > look at it as a cost benefit analysis, and not be willing to afford infin= ite > cost to the "proxies may get exploited" line of reasoning. I don't mean t= o > dismiss the issue by any means, but merely to say that there is a limit t= o > how much we should accomodate these things. > > -Ian (hopefully that's a sufficiently cryptic response to maintain my > previously stated neutral stance) > > On Thu, Mar 10, 2011 at 3:30 AM, Adam Barth wrote: > >> Thanks for having an open mind Joel. Let's start with some basic >> assumptions: >> >> 1) Attacks only get better over time. Over the (hopefully) many years >> folks will be using this protocol, the attacks we know about today >> will continue to exist, and security researchers will continue to >> learn more techniques and improve their attacks. That means we should >> design protocols with a margin of safety rather than pushing up >> against the razor edge of what we can reliably exploit today. >> Admitted, this aspect of security is somewhat of an art, and at some >> point we'll need to defer to the judgement of security experts as to >> how much of a margin we need for safety. >> >> 2) If an attacker can choose a moderately long sequence of bytes of >> the wire, we lose. More specifically, we can construct attacks today >> that abuse certain configurations of proxies using a moderate length >> of chosen bytes. Because of (1), we should expect the length of these >> sequences and the amount of damage attacker can cause with them to >> increase over time. The story would be different if we had some solid >> reasoning about lower bounds on length or upper bounds on damage, but >> we don't. >> >> For simplicity, let's consider the base framing protocol: >> >> >> http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06#secti= on-4.3 >> >> Let's assume we're only going to mask the extension data and the >> application data. That leds approximately 10 bytes at the beginning >> of the frame that's unmasked. Are these bytes under the control of >> the attacker? In large part, they are. For example, the attacker is >> relatively free to select the payload length. The attacker is also >> likely to have a large amount of control over the opcode (recall that >> the attacker can drive the protocol state machine into relatively >> arbitrary states). As for the various reserved bits, we don't know >> very much about how these bits will be used, but if they're likely to >> be at least partially under the influence of the attacker. >> >> Worse, consider the case where the attacker sends a sequence of very >> short (e.g., zero or one byte) messages. Now the attacker can control >> (or can strongly influence) an appreciable fraction of the bytes on >> the wire. Additionally, the attacker gets feedback (i.e., by seeing >> the bytes that arrive at the server) and can dynamically adjust >> subsequent messages based on this feedback. >> >> So, does the above add up to an attack I can demonstrate today? No. >> Is there reasonable evidence that attackers will be able to stich >> together the above weaknesses to construct an attack in the future? >> Yes. Given what we know today, my view is that not masking the entire >> frame is an unacceptable level of risk. >> >> Adam >> >> >> On Thu, Mar 10, 2011 at 3:05 AM, Joel Martin >> wrote: >> > I've been following this discussion pretty closely and I'm willing to >> change >> > my mind if Adam (or somebody else) can clearly lay out a threat model >> that >> > isn't easily addressed by minor tweaking. I really am interested in wh= at >> > real threat may exist and not just being stubborn. Please enlighten me= . >> > As somebody else has proposed, the allowable range of values in the >> length >> > field can always be reduced in the future by fragmenting to avoid >> _specific_ >> > known vulnerable intermediaries (in the implementations without even >> > changing the protocol). I.e. if "GET\n" is a problem, then client >> > implementations can just never send that value. >> > I suspect most would agree that masking of everything is better than >> > stalling the protocol any longer, but if Adam is the only objector and >> the >> > browser folks are okay with masking only payload then perhaps we shoul= d >> move >> > forward with it. >> > Joel Martin (kanaka) >> > On Thu, Mar 10, 2011 at 1:39 PM, Willy Tarreau wrote: >> >> >> >> On Thu, Mar 10, 2011 at 02:25:28AM -0800, Brian wrote: >> >> > By my count, we have six voices in favor so far, including myself: >> >> > Andy Green >> >> > Ytaka Takeda >> >> > Greg Wilkins >> >> > Willy Tarreau >> >> > Joel Martin >> >> > Brian McKelvey >> >> > >> >> > One on record as not having a strong opinion one way or the other: >> >> > Ian Fette >> >> > >> >> > And one opposed: >> >> > Adam Barth >> >> > >> >> > >> >> > Adam's curt and patronizing reply is once again unenlightening as t= o >> >> > any viable reason why we need to mask the frame header as well as t= he >> >> > payload, beyond just his gut feeling on the matter. I'd like to >> >> > re-assert that since the only field under a potential hacker's >> control >> >> > is the length (and potentially rsv bits via undefined extensions in >> >> > the future) that the practical possibility of the frame header bein= g >> >> > used for an attack that actually accomplishes anything is so remote >> >> > it's utterly laughable. >> >> >> >> I'd like to add that it's important to remember that this controllabl= e >> >> length is not even at the beginning of the frame, and that there are >> >> uncontrollable bytes before. >> >> >> >> Regards, >> >> Willy >> >> >> >> _______________________________________________ >> >> 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 >> > >> > >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> > > --0003255736e6728f49049e1f9d26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That said, looking at the wiki again, I am not really sure I understand the= benefits that=C2=A0intermediaries=C2=A0would get from this. Either way it = looks like they need to be able to pick out frame boundaries, and to do tha= t reliably I think they have to read frame header 1, see how long that fram= e is, and basically skip that many bytes to get to frame 2. I don't und= erstand how they could do it without parsing the frame header for frame 1. = The masking doesn't make it that difficult to get to the frame header, = you have to xor on the order of 10 bytes. A lot of the complexity savings s= eem predicated on the thought that we may choose a different, stream-based = masking algorithm, which I thought we already decided against because of so= me of those exact issues?

Again, I'm not against it, but I don't really see en= ough benefit to say I'm for it either.

-Ian
<= br>
2011/3/10 Ian Fette (=E3=82=A4=E3=82=A2=E3=83= =B3=E3=83=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) <ifette@google.com>
The attacker is relatively free to select t= he length of the message, but that may or may not translate into the length= of a given frame. For instance, a browser may decide to fragment a large m= essage. Looking at the base framing, the attacker can also choose between a= text and binary frame. In practice, I would be surprised if the attacker h= ad control over more than seventeen bits coming from a browser. We (the bro= wser at its discretion) could also choose to e.g. fragment a message if it = saw a length equal to "GET\n" or "POST" or any number o= f such keywords, though I admit that it is no sure fire defense against pot= ential attacks.=C2=A0

At the end of the day, I think you are right in saying that = it does open up additional attack surface and potential. The question is ho= w plausible do we believe such an attack to be, what is the potential damag= e, and what do we gain in exchange? The handshake in theory means that we&#= 39;re looking at attacks against ill-formed proxies as the primary attack t= arget/vector. We can argue about whether these are likely to grow in number= or shrink in number, but at the end of the day it is a relatively small nu= mber of endpoints that are already exploitable via other means as you demon= strated. I am willing to live with masking, but at some point I do think we= need to look at it as a cost benefit analysis, and not be willing to affor= d infinite cost to the "proxies may get exploited" line of reason= ing. I don't mean to dismiss the issue by any means, but merely to say = that there is a limit to how much we should accomodate these things.

-Ian (hopefully that's a sufficiently cryptic respo= nse to maintain my previously stated neutral stance)
<= div class=3D"h5">

On Thu, Mar 10, 2011 a= t 3:30 AM, Adam Barth <ietf@adambarth.com> wrote:
Thanks for having an open mind Joel. =C2=A0L= et's start with some basic assumptions:

1) Attacks only get better over time. =C2=A0Over the (hopefully) many years=
folks will be using this protocol, the attacks we know about today
will continue to exist, and security researchers will continue to
learn more techniques and improve their attacks. =C2=A0That means we should=
design protocols with a margin of safety rather than pushing up
against the razor edge of what we can reliably exploit today.
Admitted, this aspect of security is somewhat of an art, and at some
point we'll need to defer to the judgement of security experts as to how much of a margin we need for safety.

2) If an attacker can choose a moderately long sequence of bytes of
the wire, we lose. =C2=A0More specifically, we can construct attacks today<= br> that abuse certain configurations of proxies using a moderate length
of chosen bytes. =C2=A0Because of (1), we should expect the length of these=
sequences and the amount of damage attacker can cause with them to
increase over time. =C2=A0The story would be different if we had some solid=
reasoning about lower bounds on length or upper bounds on damage, but
we don't.

For simplicity, let's consider the base framing protocol:

http://tools.ietf.org/html/draft-ietf-hyb= i-thewebsocketprotocol-06#section-4.3

Let's assume we're only going to mask the extension data and the application data. =C2=A0That leds approximately 10 bytes at the beginning of the frame that's unmasked. =C2=A0Are these bytes under the control o= f
the attacker? =C2=A0In large part, they are. =C2=A0For example, the attacke= r is
relatively free to select the payload length. =C2=A0The attacker is also likely to have a large amount of control over the opcode (recall that
the attacker can drive the protocol state machine into relatively
arbitrary states). =C2=A0As for the various reserved bits, we don't kno= w
very much about how these bits will be used, but if they're likely to be at least partially under the influence of the attacker.

Worse, consider the case where the attacker sends a sequence of very
short (e.g., zero or one byte) messages. =C2=A0Now the attacker can control=
(or can strongly influence) an appreciable fraction of the bytes on
the wire. =C2=A0Additionally, the attacker gets feedback (i.e., by seeing the bytes that arrive at the server) and can dynamically adjust
subsequent messages based on this feedback.

So, does the above add up to an attack I can demonstrate today? =C2=A0No. Is there reasonable evidence that attackers will be able to stich
together the above weaknesses to construct an attack in the future?
Yes. =C2=A0Given what we know today, my view is that not masking the entire=
frame is an unacceptable level of risk.

Adam


On Thu, Mar 10, 2011 at 3:05 AM, Joel Martin <hybi@martintribe.org> wrote:
> I've been following this discussion pretty closely and I'm wil= ling to change
> my mind if Adam (or somebody else) can clearly lay out a threat model = that
> isn't easily addressed by minor tweaking. I really am interested i= n what
> real threat may exist and not just being stubborn. Please enlighten me= .
> As somebody else has proposed, the allowable range of values in the le= ngth
> field can always be reduced in the future by fragmenting to avoid _spe= cific_
> known vulnerable intermediaries (in the implementations without even > changing the protocol). I.e. if "GET\n" is a problem, then c= lient
> implementations can just never send that value.
> I suspect most would agree that masking of everything is better than > stalling the protocol any longer, but if Adam is the only objector and= the
> browser folks are okay with masking only payload then perhaps we shoul= d move
> forward with it.
> Joel Martin (kanaka)
> On Thu, Mar 10, 2011 at 1:39 PM, Willy Tarreau <w@1wt.eu> wrote:
>>
>> On Thu, Mar 10, 2011 at 02:25:28AM -0800, Brian wrote:
>> > By my count, we have six voices in favor so far, including my= self:
>> > Andy Green
>> > Ytaka Takeda
>> > Greg Wilkins
>> > Willy Tarreau
>> > Joel Martin
>> > Brian McKelvey
>> >
>> > One on record as not having a strong opinion one way or the o= ther:
>> > Ian Fette
>> >
>> > And one opposed:
>> > Adam Barth
>> >
>> >
>> > Adam's curt and patronizing reply is once again unenlight= ening as to
>> > any viable reason why we need to mask the frame header as wel= l as the
>> > payload, beyond just his gut feeling on the matter. =C2=A0I&#= 39;d like to
>> > re-assert that since the only field under a potential hacker&= #39;s control
>> > is the length (and potentially rsv bits via undefined extensi= ons in
>> > the future) that the practical possibility of the frame heade= r being
>> > used for an attack that actually accomplishes anything is so = remote
>> > it's utterly laughable.
>>
>> I'd like to add that it's important to remember that this = controllable
>> length is not even at the beginning of the frame, and that there a= re
>> uncontrollable bytes before.
>>
>> Regards,
>> Willy
>>
>> _______________________________________________
>> 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
>
>
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi


--0003255736e6728f49049e1f9d26-- From jamie@shareable.org Thu Mar 10 04:05:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC543A6A3F for ; Thu, 10 Mar 2011 04:05:22 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLps56SqoTNp for ; Thu, 10 Mar 2011 04:05:22 -0800 (PST) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id CF8C63A6A2B for ; Thu, 10 Mar 2011 04:05:21 -0800 (PST) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1PxedV-0001yM-T7; Thu, 10 Mar 2011 12:06:33 +0000 Date: Thu, 10 Mar 2011 12:06:33 +0000 From: Jamie Lokier To: Andy Green Message-ID: <20110310120633.GJ29234@shareable.org> References: <4D77FB84.9010104@warmcat.com> <4D789223.8010208@warmcat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D789223.8010208@warmcat.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Yutaka_Takeda@playstation.sony.com, hybi@ietf.org Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 12:05:22 -0000 Andy Green wrote: > However this "dribbling compression codes after close" thing is not a > problem in the real world that I can see and at most maybe needs a note > that before closing a socket compressed like this, you may need to drain > it in a loop polling it with no timeout and POLLIN until nothing is left > before calling close(). Polling in that way will not make this reliable, because you cannot be sure the OS has recieved the final bytes. The assumption that the close-message and trailing bytes always occupy the same packet is not reliable. It is easy to construct TCP scenarios where the last byte is split off at the sender, due to timing at the receiver. It is not likely to be a _significant_ problem in the real world. Many WebSocket apps likely don't need orderly close semantics either.[1] But if we don't care about making orderly close reliable in corner cases, there is no point having orderly close at all, as it defeats the point of it. -- Jamie [1] (I expect many "big" apps and toolkits will end up doing what I did: treat WS as an unreliable connection, and do their own framing, ordering, duplicate detection, keepalives and message retrying at the application layer, due to WS's sort-of-but-not-really attempts to be reliable, and because that matches up well with fallbacks to HTTP) From tyoshino@google.com Thu Mar 10 04:11:32 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569443A69F9 for ; Thu, 10 Mar 2011 04:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.752 X-Spam-Level: X-Spam-Status: No, score=-105.752 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkKAFA7P2t1U for ; Thu, 10 Mar 2011 04:11:20 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 925CF3A6A87 for ; Thu, 10 Mar 2011 04:11:12 -0800 (PST) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p2ACCTIR011935 for ; Thu, 10 Mar 2011 04:12:29 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299759149; bh=tL5Vvz9w8QjR2vfLYCDq98644sM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=inQP0T9MWASPCiqaUiFaIHmqfHRTuQ8lwBhkGYBMR/SQmRUhxDLcnNTeFvmDH/PLs +ZGjnI9dxH7lPspsQLbRQ== Received: from iyf13 (iyf13.prod.google.com [10.241.50.77]) by kpbe12.cbf.corp.google.com with ESMTP id p2ACCS5t019668 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 10 Mar 2011 04:12:28 -0800 Received: by iyf13 with SMTP id 13so1983638iyf.0 for ; Thu, 10 Mar 2011 04:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=V+8zEU4t9avFkx6ww5E1CAYJrG4/uSNg8BRHwcKXexY=; b=R1fAzOkcriYF3b5S7wn/IH+sH4xsomKHMI8wm0lAdlbQSv517+LBcHlR1JIV0FeQG0 s0+g7VOtIuGjY/cGTHdA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=xYQDlCjNaawG3ALcxabfy5kIbZp8JwvVHDOWR3gqWO8P8YJ4CQZGUEVKQyf0ZDKa/i I3lCHFeBf3m3jeju31eQ== Received: by 10.43.61.20 with SMTP id wu20mr9684729icb.371.1299759148135; Thu, 10 Mar 2011 04:12:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.14.141 with HTTP; Thu, 10 Mar 2011 04:12:06 -0800 (PST) In-Reply-To: <4D789223.8010208@warmcat.com> References: <4D77FB84.9010104@warmcat.com> <4D789223.8010208@warmcat.com> From: Takeshi Yoshino Date: Thu, 10 Mar 2011 21:12:06 +0900 Message-ID: To: Andy Green Content-Type: multipart/alternative; boundary=bcaec51a833851766e049e1fc272 X-System-Of-Record: true Cc: Yutaka_Takeda@playstation.sony.com, hybi@ietf.org Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 12:11:33 -0000 --bcaec51a833851766e049e1fc272 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 10, 2011 at 17:56, Andy Green wrote: > On <03%2F10%2F2011> <03%2F10%2F2011> <03%2F10%2F2011>03/10/2011 05:22 AM, > Somebody in the thread at some point said: > > Hi - > > I'm going over the threads trying to figure out what i need to do, and I >> will admit that this one has me a bit stumped. If we adopt yoshino-san's >> proposal [1] to only compress the payload of the frame, does that put >> this issue to rest? >> >> [1] http://www.ietf.org/mail-archive/web/hybi/current/msg06674.html >> > > Payload only compression would be nice. > > However this "dribbling compression codes after close" thing is not a > problem in the real world that I can see and at most maybe needs a note that > before closing a socket compressed like this, you may need to drain it in a > loop polling it with no timeout and POLLIN until nothing is left before > calling close(). > As Jamie created a new thread, let's talk about this there. > > Also one note on Yoshino's language to describe the compression actions it > mixes Z_ nomenclature that zlib uses and hex packets on the wire, if this > hex trailer that he mentions is a byproduct of Z_FINISH or whatever it might > be clearer to an implementer that he can generate it like that and forget > mentioning magic hex. > > Basically I agree your point here that we should use only deflate terminology in definition, and append implementation note to it using zlib nomenclature, while avoiding mentioning magic hex as you say. In my proposal ( http://www.ietf.org/mail-archive/web/hybi/current/msg06642.html the bottom of the message), I used one magic hex "0x00 0x00 0xff 0xff" to include optimization on deflate adopted by PPP and explain what implementor have to do quickly. That can be changed to ... something like "0 byte length block with BTYPE=00 excluding headers", but it's not helpful in this context IMO. This is originally a part of byproduct of zlib's de-facto standard way to flush deflated stream, but operation introduced by RFC 1979 like cutting, removing on sender, re-appending the bytes on receiver is out of scope of RFC1951. Maybe, just referring RFC1979 in the explanation of receiver's action would be fine? > > -Andy > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --bcaec51a833851766e049e1fc272 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 10, 2011 at 17:56, Andy Green <andy@= warmcat.com> wrote:
On 03/10/201= 1 05:22 AM, Somebody in the thread at some point said:

Hi -

I'm going over the threads trying to figure out what i need to do, and = I
will admit that this one has me a bit stumped. If we adopt yoshino-san'= s
proposal [1] to only compress the payload of the frame, does that put
this issue to rest?

[1] http://www.ietf.org/mail-archive/web/hybi/current/ms= g06674.html

Payload only compression would be nice.

However this "dribbling compression codes after close" thing is n= ot a problem in the real world that I can see and at most maybe needs a not= e that before closing a socket compressed like this, you may need to drain = it in a loop polling it with no timeout and POLLIN until nothing is left be= fore calling close().

As Jamie created a new thread, let's t= alk about this there.
=A0

Also one note on Yoshino's language to describe the compression actions= it mixes Z_ nomenclature that zlib uses and hex packets on the wire, if th= is hex trailer that he mentions is a byproduct of Z_FINISH or whatever it m= ight be clearer to an implementer that he can generate it like that and for= get mentioning magic hex.


Basically = I agree your point here that we should use only deflate terminology in defi= nition, and append implementation note to it using zlib nomenclature, while= avoiding mentioning magic hex as you say.

In my proposal (http://www.ietf.org/= mail-archive/web/hybi/current/msg06642.html=A0the bottom of the message= ), I used one magic hex "0x00 0x00 0xff 0xff" to include optimiza= tion on deflate adopted by PPP and explain what implementor have to do quic= kly. That can be changed to ... something like "0 byte length block wi= th BTYPE=3D00 excluding headers", but it's not helpful in this con= text IMO. This is originally a part of byproduct of zlib's de-facto sta= ndard way to flush deflated stream, but operation introduced by RFC 1979 li= ke cutting, removing on sender, re-appending the bytes on receiver is out o= f scope of RFC1951. Maybe, just referring RFC1979 in the explanation of rec= eiver's action would be fine?
=A0

-Andy
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--bcaec51a833851766e049e1fc272-- From andy.warmcat.com@googlemail.com Thu Mar 10 04:11:38 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE263A6A8A for ; Thu, 10 Mar 2011 04:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TzOumKS5yge for ; Thu, 10 Mar 2011 04:11:37 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 53F483A69DC for ; Thu, 10 Mar 2011 04:11:36 -0800 (PST) Received: by wyb42 with SMTP id 42so1564299wyb.31 for ; Thu, 10 Mar 2011 04:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KOXOP79Z+UZ6aNVyc6jakxVtU/Q9TcKgSnrRgLALjUk=; b=gdJSWqmMRbktWsbxg7wgYXgSzJJU6qLNCSdjzxj3ruzjLWPyntNG1QuCYLBjKok5FZ zSfGycCZ54/6hkKXUS+3U2D5/oe2RlGuf6wP6lqX8pBF9/qMftJrJFWs8k8WNzKz4E9Q ogs8aezgRPN7SbOi+n6qUctYXR1bQGqmSo+eU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=TCzzJzmcg5/JiXyVPpcnvZWdUj4Sxgbe6V97Mg31qaOhNCQtd59uo4odgBhvZJ25L+ 5e4Gkm/4lruEuME9s4cBdsbwuW6177EQDqB9HKHJ7Emhpoy0JSaV22OaNI0Xk7thTR2E lP98ZvZjG4HsdDjI8ZViHbUtZ8+0APImJn1Pg= Received: by 10.227.130.99 with SMTP id r35mr6894727wbs.221.1299759173457; Thu, 10 Mar 2011 04:12:53 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id x1sm684358wbh.2.2011.03.10.04.12.51 (version=SSLv3 cipher=OTHER); Thu, 10 Mar 2011 04:12:52 -0800 (PST) Sender: Andy Green Message-ID: <4D78C042.9080001@warmcat.com> Date: Thu, 10 Mar 2011 12:12:50 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: Adam Barth References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <20110310103914.GA32389@1wt.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 12:11:38 -0000 On 03/10/2011 11:30 AM, Somebody in the thread at some point said: Hi - > Admitted, this aspect of security is somewhat of an art, and at some > point we'll need to defer to the judgement of security experts as to > how much of a margin we need for safety. The only things we should be deferring to are correct explanations that hold water for the other people on the list, and verifiable claims that can be reproduced. Frankly because someone says they are a "security expert" doesn't exempt them from explaining their reasoning just because they feel they are awesome, and their reasoning should make sense. It's just that if they call themselves a 'security expert', we are justified in expecting a very high level of reasoning and correctness in what they are telling, not that we sit in a circle around them accepting pearls of wisdom without doubts. > 2) If an attacker can choose a moderately long sequence of bytes of > the wire, we lose. More specifically, we can construct attacks today > that abuse certain configurations of proxies using a moderate length > of chosen bytes. Because of (1), we should expect the length of these Can you define what these proxies are and put a number on 'moderate'? These are claims of specific successful attacks you are referring to now so you should be able to be very specific indeed about the length of controlled data that was needed. Why are you using a word like "moderate" when you have an actual number? > sequences and the amount of damage attacker can cause with them to > increase over time. The story would be different if we had some solid > reasoning about lower bounds on length or upper bounds on damage, but > we don't. > > For simplicity, let's consider the base framing protocol: > > http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06#section-4.3 > > Let's assume we're only going to mask the extension data and the > application data. That leds approximately 10 bytes at the beginning > of the frame that's unmasked. Are these bytes under the control of > the attacker? In large part, they are. For example, the attacker is > relatively free to select the payload length. The attacker is also Although there can be up to 8 bytes reserved for length, to control that from Javascript land you need to allocate an object of the length you wanted, and you don't know the fragmentation policy of the browser either. So if you do allocate the 1GByte object needed to get a 4-byte ASCII string in the length, you don't know it won't go out as a bunch of smaller guys using CONTINUATION and even with the 2-byte length field you now don't control at all -- in the interests of latency reduction that is highly likely when you tried to arrange for a 1GB message. > likely to have a large amount of control over the opcode (recall that > the attacker can drive the protocol state machine into relatively > arbitrary states). As for the various reserved bits, we don't know > very much about how these bits will be used, but if they're likely to > be at least partially under the influence of the attacker. Well, this is FUD. But, given the subject, we have to accept a little FUD is part of discussing 'unknown attacks'. However --> > Worse, consider the case where the attacker sends a sequence of very > short (e.g., zero or one byte) messages. Now the attacker can control > (or can strongly influence) an appreciable fraction of the bytes on > the wire. Additionally, the attacker gets feedback (i.e., by seeing > the bytes that arrive at the server) and can dynamically adjust > subsequent messages based on this feedback. At this point, we must remind ourselves that all of this is ONLY in the context of an established websocket connection between two fixed endpoints, one of which definitely speaks client websockets and the other of which definitely speaks server websockets. So the only kind of attacks that are possible from the client is to hack the server websockets implementation, which hopefully the server author took care to try to avoid being possible, or to try to affect a broken intermediary via websockets. Alongside the power of the future to magically make attacks more possible, in fact over time people will also harden and uplevel their intermediaries too, and they will become websocket-aware in a deeper way. Of course, that'll happen quicker if someone identifies the claimed vulnerable ones. However in spite you don't seem to have any doubts they exist, I never saw you claim to know which proxies are vulnerable, just that there is some indirect evidence that they may exist. As Joel pointed out it's also open to us to uplevel the protocol. > So, does the above add up to an attack I can demonstrate today? No. > Is there reasonable evidence that attackers will be able to stich > together the above weaknesses to construct an attack in the future? > Yes. Given what we know today, my view is that not masking the entire > frame is an unacceptable level of risk. I am still waiting to be able to write a tool that can test proxies for and demonstrate the attack you were writing about 'yesterday'. -Andy From andy.warmcat.com@googlemail.com Thu Mar 10 04:15:35 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22C053A6842 for ; Thu, 10 Mar 2011 04:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV+1Vph+RJh9 for ; Thu, 10 Mar 2011 04:15:34 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6032F3A69DC for ; Thu, 10 Mar 2011 04:15:29 -0800 (PST) Received: by wyb42 with SMTP id 42so1567632wyb.31 for ; Thu, 10 Mar 2011 04:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iQk9m1wmz56Uh4ZJp1mqL4V2p/6bn+8bNBIK3Bw1Hk8=; b=EzfI7stXwY/LEmpdRPmZoNInOx6WMn5xPMWFdGFxH33ur0Zyn83ZMYdi45x75fUcNy K6XDVKDpQm4NwCWQ1txXY0VWEQFUOQzcX5mV13ex65QeuetFX+yi43Qx8SIK/Y1jcqAU 20icBQVt3NjdoJ7jL5RcfHxeQNFaaSjFNR4Lc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=j518rxHXarA7gs3V9GR2ZjRBrn0AX6xGh1kbLyZWiEP866zgOGd4Yw+UjHW25z/fcN m/gEF7tJJqrka4SOm6bCYaCcCLH81+1aswcMZCg2Q50RXZcjoO1Nrrt6df1qtN5P0ojA C4p+9LbiZwRC72x223LoTwi4i1EvulrqXpv8I= Received: by 10.227.174.79 with SMTP id s15mr3216723wbz.76.1299759406646; Thu, 10 Mar 2011 04:16:46 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id x1sm2369707wbh.8.2011.03.10.04.16.45 (version=SSLv3 cipher=OTHER); Thu, 10 Mar 2011 04:16:45 -0800 (PST) Sender: Andy Green Message-ID: <4D78C12C.1080108@warmcat.com> Date: Thu, 10 Mar 2011 12:16:44 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: Takeshi Yoshino References: <4D77FB84.9010104@warmcat.com> <4D789223.8010208@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yutaka_Takeda@playstation.sony.com, hybi@ietf.org Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 12:15:35 -0000 On 03/10/2011 12:12 PM, Somebody in the thread at some point said: Hi - > Also one note on Yoshino's language to describe the compression > actions it mixes Z_ nomenclature that zlib uses and hex packets on > the wire, if this hex trailer that he mentions is a byproduct of > Z_FINISH or whatever it might be clearer to an implementer that he > can generate it like that and forget mentioning magic hex. > > > Basically I agree your point here that we should use only deflate > terminology in definition, and append implementation note to it using > zlib nomenclature, while avoiding mentioning magic hex as you say. > > In my proposal > (http://www.ietf.org/mail-archive/web/hybi/current/msg06642.html the > bottom of the message), I used one magic hex "0x00 0x00 0xff 0xff" to > include optimization on deflate adopted by PPP and explain what > implementor have to do quickly. That can be changed to ... something > like "0 byte length block with BTYPE=00 excluding headers", but it's not > helpful in this context IMO. This is originally a part of byproduct of > zlib's de-facto standard way to flush deflated stream, but operation > introduced by RFC 1979 like cutting, removing on sender, re-appending > the bytes on receiver is out of scope of RFC1951. Maybe, just referring > RFC1979 in the explanation of receiver's action would be fine? Well my issue with it was I don't know what code to write as described, it sounds like I should fill up a four byte bufer with constants and write() it out. I guess all the actions fall into simple zlib calls with the right Z_ flags, eg, it really means you must call the last guy with Z_FINISH. However else it's described it'll be helpful to implementers to give examples where it isn't clear in Z_ nomenclature as well. -Andy From andy.warmcat.com@googlemail.com Thu Mar 10 04:20:40 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B669C3A696F for ; Thu, 10 Mar 2011 04:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRBj4hxJJYgp for ; Thu, 10 Mar 2011 04:20:39 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 50D5B3A691D for ; Thu, 10 Mar 2011 04:20:39 -0800 (PST) Received: by wyb42 with SMTP id 42so1572041wyb.31 for ; Thu, 10 Mar 2011 04:21:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=F/r7KEt9hj4/PMuEkVPgY1YwXISKRxQrx08rZN+94C8=; b=Vqszfu3VB9MwiU2KDYnlXzYcO89D9KUzL8uYGa0tS8Ge4MCR+pyA2DWwgNz/MLIrLs wDBF33h/M08MH8E07lQKotTERIyVbMUN8yHsdPiL55q4PQyR3L2DaW/GdiVsDSxOE3Ek lcVyhwQLW5tls3zvNvs8r9d3N7BK1lWH04n+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=W0Pcyo0CYlclMc++TkJk8Eq3TRlp9Wz/crvw9ii6MkZHuSi/7r9CbbiuVNdBYnY7Hr kKH5VoqGAURfnRcgNjbnr7A3IDmvBqniPwuaQ/F6tjBOhYbVBa8OxNElQ3jvgYyxXti+ yr6RLm/o4nfggZZUoXn6pjX/1Gzl7vHeDmbAM= Received: by 10.227.7.87 with SMTP id c23mr1145455wbc.108.1299759716470; Thu, 10 Mar 2011 04:21:56 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id w25sm2377148wbd.23.2011.03.10.04.21.55 (version=SSLv3 cipher=OTHER); Thu, 10 Mar 2011 04:21:56 -0800 (PST) Sender: Andy Green Message-ID: <4D78C262.2060808@warmcat.com> Date: Thu, 10 Mar 2011 12:21:54 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: Jamie Lokier References: <4D775D69.8010808@warmcat.com> <4D777402.3010101@warmcat.com> <4D778F5C.3020404@warmcat.com> <20110310115119.GI29234@shareable.org> In-Reply-To: <20110310115119.GI29234@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, Yutaka_Takeda@playstation.sony.com Subject: Re: [hybi] TCP packet boundaries must not be assumed (was Re: With deflate-stream, Close frame doesn't work as an end of data marker) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 12:20:40 -0000 On 03/10/2011 11:51 AM, Somebody in the thread at some point said: Hi - > You also cannot depend on TCP_NODELAY preventing packet aggregation. > > There are many corner cases, but here is a few simple ones: When there > is any bottleneck such as congestion, receiver too slow, receiver busy > or not enough bandwidth somewhere, the sender will delay sending, or > resend, and so may aggregate more data into previously queued packets. Hum fair enough, that is a good point. If I understood it, it looks like the new language from Yoshino will make this moot, because knowing the link is compressed, we know we have to specifically wait a while anyway for Z_FINISH bytes to come before close. -Andy From tyoshino@google.com Thu Mar 10 04:34:07 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 268C53A6936 for ; Thu, 10 Mar 2011 04:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.765 X-Spam-Level: X-Spam-Status: No, score=-105.765 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjVmVikhoofP for ; Thu, 10 Mar 2011 04:34:03 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C854C3A6952 for ; Thu, 10 Mar 2011 04:34:02 -0800 (PST) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id p2ACZJhZ026866 for ; Thu, 10 Mar 2011 04:35:19 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299760519; bh=BhzRlYAQYzUvfJWqk8mT4cxsZhI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=WYHmNhoksCBVg4dZIIGX2tE/RL8m3W9ou9DukuOwkerTu6oNWvSpTdLzEbgny5bMB hVVhePtImjW3WgvWGATNA== Received: from iwl42 (iwl42.prod.google.com [10.241.67.234]) by kpbe11.cbf.corp.google.com with ESMTP id p2ACZIEO001435 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 10 Mar 2011 04:35:18 -0800 Received: by iwl42 with SMTP id 42so2013130iwl.0 for ; Thu, 10 Mar 2011 04:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jBrPL5BiA6QCNTsdTqTxZcRq7s9lzH5YCJ6itAnovY0=; b=WyM5z4vxH5KwNrE6LwQ8yRcvhky5Y0IJZnHsezHDL0IxbQbtvsUWX5BIOJxvE3trAj LaaldGrsOkGIeeRTmYsw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=pI2UidAMA/P/heOGYc7epy7+OQZMQXN5cWDkUTm7UqwETGEWkjcF+aRCNKfCZaAQG7 XGZQ9cxwHvmAa5mWKvYg== Received: by 10.231.193.170 with SMTP id du42mr6083754ibb.15.1299760518133; Thu, 10 Mar 2011 04:35:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.14.141 with HTTP; Thu, 10 Mar 2011 04:34:57 -0800 (PST) In-Reply-To: <4D78C12C.1080108@warmcat.com> References: <4D77FB84.9010104@warmcat.com> <4D789223.8010208@warmcat.com> <4D78C12C.1080108@warmcat.com> From: Takeshi Yoshino Date: Thu, 10 Mar 2011 21:34:57 +0900 Message-ID: To: Andy Green Content-Type: multipart/alternative; boundary=0050450171e1f9f7d2049e201386 X-System-Of-Record: true Cc: Yutaka_Takeda@playstation.sony.com, hybi@ietf.org Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 12:34:07 -0000 --0050450171e1f9f7d2049e201386 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 10, 2011 at 21:16, Andy Green wrote: > On <03%2F10%2F2011>03/10/2011 12:12 PM, Somebody in the thread at some > point said: > > Hi - > > Also one note on Yoshino's language to describe the compression >> actions it mixes Z_ nomenclature that zlib uses and hex packets on >> the wire, if this hex trailer that he mentions is a byproduct of >> Z_FINISH or whatever it might be clearer to an implementer that he >> can generate it like that and forget mentioning magic hex. >> >> >> Basically I agree your point here that we should use only deflate >> terminology in definition, and append implementation note to it using >> zlib nomenclature, while avoiding mentioning magic hex as you say. >> >> In my proposal >> (http://www.ietf.org/mail-archive/web/hybi/current/msg06642.html the >> bottom of the message), I used one magic hex "0x00 0x00 0xff 0xff" to >> include optimization on deflate adopted by PPP and explain what >> implementor have to do quickly. That can be changed to ... something >> like "0 byte length block with BTYPE=00 excluding headers", but it's not >> helpful in this context IMO. This is originally a part of byproduct of >> zlib's de-facto standard way to flush deflated stream, but operation >> introduced by RFC 1979 like cutting, removing on sender, re-appending >> the bytes on receiver is out of scope of RFC1951. Maybe, just referring >> RFC1979 in the explanation of receiver's action would be fine? >> > > Well my issue with it was I don't know what code to write as described, it > sounds like I should fill up a four byte bufer with constants and write() it > out. > > I guess all the actions fall into simple zlib calls with the right Z_ > flags, eg, it really means you must call the last guy with Z_FINISH. However > else it's described it'll be helpful to implementers to give examples where > it isn't clear in Z_ nomenclature as well. > > -Andy > OK. So we can add an implementation note like this. Senders using this extension MUST apply RFC 1951 DEFLATE to all the bytes of > the application data portion of data frames. Senders MAY include multiple > blocks in a frame. Senders MAY use blocks of any type as defined in RFC > 1951. Senders MUST use the algorithm described in Section 2.1 of RFC1979 to > align compressed data to byte boundary. Senders MAY keep using the same LZ77 > sliding window for multiple frames. If you're using zlib for applying DEFLATE compression, specify Z_SYNC_FLUSH when you flush the last octets of application data for each frame (in case the last block is non-compressed block (BTYPE=00), append one empty compressed block (BTYPE=01)), and then strip the last 4 octets from the compressed octets. Receivers MUST append 0x00 0x00 0xff 0xff to the application data portion > and decompress it using DEFLATE to decode the original application data. > Receivers MUST keep using the same LZ77 sliding window for all the frames of > the same WebSocket connection. Receivers MUST assume the senders use 32768 > byte LZ77 sliding window. If you're using zlib for applying DEFLATE compression, for each received frame, concatenate 4 octets 0x00 0x00 0xff 0xff and the application data, and then supply the resulting bytes to zlib and use the uncompressed data. ---- There might be some function prepared on zlib that performs these procedure, but I don't know that (i'm not so familiar with the original C lang zlib). And, e.g. zlib wrapper of Python which I'm using to write WebSocket server doesn't expose such method at all. I thought simple uncompress/compress/flush methods are at least available on most of platforms and built this text. --0050450171e1f9f7d2049e201386 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 10, 2011 at 21:16, Andy Green <andy@warmcat.com>= ; wrote:
On <= a href=3D"tel:03%2F10%2F2011" target=3D"_blank">03/10/2011 12:12 PM, So= mebody in the thread at some point said:

Hi -

=A0 =A0Also one note on Yoshino's language to describe the compression=
=A0 =A0actions it mixes Z_ nomenclature that zlib uses and hex packets on<= br> =A0 =A0the wire, if this hex trailer that he mentions is a byproduct of =A0 =A0Z_FINISH or whatever it might be clearer to an implementer that he<= br> =A0 =A0can generate it like that and forget mentioning magic hex.


Basically I agree your point here that we should use only deflate
terminology in definition, and append implementation note to it using
zlib nomenclature, while avoiding mentioning magic hex as you say.

In my proposal
(http://www.ietf.org/mail-archive/web/hybi/current/msg06= 642.html the
bottom of the message), I used one magic hex "0x00 0x00 0xff 0xff"= ; to
include optimization on deflate adopted by PPP and explain what
implementor have to do quickly. That can be changed to ... something
like "0 byte length block with BTYPE=3D00 excluding headers", but= it's not
helpful in this context IMO. This is originally a part of byproduct of
zlib's de-facto standard way to flush deflated stream, but operation introduced by RFC 1979 like cutting, removing on sender, re-appending
the bytes on receiver is out of scope of RFC1951. Maybe, just referring
RFC1979 in the explanation of receiver's action would be fine?

Well my issue with it was I don't know what code to write as described,= it sounds like I should fill up a four byte bufer with constants and write= () it out.

I guess all the actions fall into simple zlib calls with the right Z_ flags= , eg, it really means you must call the last guy with Z_FINISH. However els= e it's described it'll be helpful to implementers to give examples = where it isn't clear in Z_ nomenclature as well.

-Andy

OK. So we can add an implementation note= like this.

Senders using this extension MUST apply RFC 1951 DEFLATE to all the bytes o= f the application data portion of data frames. Senders MAY include multiple= blocks in a frame. Senders MAY use blocks of any type as defined in RFC 19= 51. Senders MUST use the algorithm described in Section 2.1 of RFC1979 to a= lign compressed data to byte boundary. Senders MAY keep using the same LZ77= sliding window for multiple frames.

If you're using zlib for applying DEFLATE compressi= on, specify Z_SYNC_FLUSH when you flush the last octets of application data= for each frame (in case the last block is non-compressed block (BTYPE=3D00= ), append one empty compressed block (BTYPE=3D01)), and then strip the last= 4 octets from the compressed octets.

Receivers MUST append 0x00 0x00 0xff 0xff to the application data portion a= nd decompress it using DEFLATE to decode the original application data. Rec= eivers MUST keep using the same LZ77 sliding window for all the frames of t= he same WebSocket connection. Receivers MUST assume the senders use 32768 b= yte LZ77 sliding window.

If you're using zlib for applying DEFLAT= E compression, for each received frame, concatenate 4 octets 0x00 0x00 0xff= 0xff and the application data, and then supply the resulting bytes to zlib= and use the uncompressed data.

----

There might be some= function prepared on zlib that performs these procedure, but I don't k= now that (i'm not so familiar with the original C lang zlib). And, e.g.= zlib wrapper of Python which I'm using to write WebSocket server doesn= 't expose such method at all. I thought simple uncompress/compress/flus= h methods are at least available on most of platforms and built this text.<= /div>

--0050450171e1f9f7d2049e201386-- From gregw@intalio.com Thu Mar 10 05:48:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C89503A69BA for ; Thu, 10 Mar 2011 05:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnBCdSj4cKB5 for ; Thu, 10 Mar 2011 05:48:36 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id C09DF3A69B4 for ; Thu, 10 Mar 2011 05:48:35 -0800 (PST) Received: by vxg33 with SMTP id 33so1827635vxg.31 for ; Thu, 10 Mar 2011 05:49:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.74.66 with SMTP id r2mr529736vdv.263.1299764993084; Thu, 10 Mar 2011 05:49:53 -0800 (PST) Sender: gregw@intalio.com Received: by 10.52.169.39 with HTTP; Thu, 10 Mar 2011 05:49:52 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <20110310103914.GA32389@1wt.eu> Date: Fri, 11 Mar 2011 00:49:52 +1100 X-Google-Sender-Auth: 1DmVS24ocyQ7UPBS7z29osnSlFc Message-ID: From: Greg Wilkins To: Joel Martin Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 13:48:37 -0000 On 10 March 2011 22:05, Joel Martin wrote: > I suspect most would agree that masking of everything is better than > stalling the protocol any longer, I don't think a bad design better than no design. The reasons that I believe the tiny increase in the attack surface is an acceptable risk are: + there are no known exploits or attacks based on this. + controlling the length field is difficult + browsers can mitigate by fragmentation + the protocol can mitigate by sending hello frames (or ping/pongs) after handshake In summary, there are no known (or even imagined) attacks, and if there were, we have mitigations that are possible that can be applied by browsers, within the current specification. cheers From mcmanus@ducksong.com Thu Mar 10 07:03:29 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7519A3A69E0 for ; Thu, 10 Mar 2011 07:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mYPqPZoBh3n for ; Thu, 10 Mar 2011 07:03:28 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 784813A69CC for ; Thu, 10 Mar 2011 07:03:28 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id EFCB3102A6; Thu, 10 Mar 2011 10:04:45 -0500 (EST) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 727C010159; Thu, 10 Mar 2011 10:04:41 -0500 (EST) From: "Pat McManus @Mozilla" To: Joel Martin In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <20110310103914.GA32389@1wt.eu> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Mar 2011 10:04:58 -0500 Message-ID: <1299769498.2606.252.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 15:03:29 -0000 On Thu, 2011-03-10 at 14:05 +0300, Joel Martin wrote: > > I suspect most would agree that masking of everything is better than > stalling the protocol any longer, but if Adam is the only objector and > the browser folks are okay with masking only payload then perhaps we > should move forward with it. I object too. I think not masking the header gives up a minor security benefit for an insubstantial benefit. None of the arguments about the benefits of the change have convinced me they add up to very much. http://www.ietf.org/mail-archive/web/hybi/current/msg06689.html http://www.ietf.org/mail-archive/web/hybi/current/msg06705.html http://www.ietf.org/mail-archive/web/hybi/current/msg06718.html -- http://www.getfirefox.com/ From mcmanus@ducksong.com Thu Mar 10 07:07:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7893A69F8 for ; Thu, 10 Mar 2011 07:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLQVWFEgHuAW for ; Thu, 10 Mar 2011 07:07:22 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 05A133A69E4 for ; Thu, 10 Mar 2011 07:07:21 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id AE38F102A6; Thu, 10 Mar 2011 10:08:39 -0500 (EST) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 46F6910159 for ; Thu, 10 Mar 2011 10:08:35 -0500 (EST) From: "Pat McManus @Mozilla" To: hybi Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Mar 2011 10:08:52 -0500 Message-ID: <1299769732.2606.256.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Subject: [hybi] Firefox with WebSockets -06 demo build X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 15:07:23 -0000 Folks, For those interested in doing interop testing with me against their development trees, I have a demo (i.e. non-official, non-qa'd) build of Firefox with websockets -06 support available. It is based on the firefox 4.0 RC1 code. Builds for linux (32 and 64), os x, and windows are here: http://www.ducksong.com/misc/websockets-builds/ws-06/4.0.rc1.01/ Any testing experience (good and bad) is greatly appreciated. Regular old bugs should go off list, but if there are any protocol issues they should go to the wg list. check for "websocket" in about:config if you'd like to arm the ping/pong inactivity timer (off by default), or disable the deflate negotiation. Thanks! -Patrick -- http://www.getfirefox.com/ From andy.warmcat.com@googlemail.com Thu Mar 10 07:35:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772053A6B0E for ; Thu, 10 Mar 2011 07:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uA79Qij9X9+b for ; Thu, 10 Mar 2011 07:35:14 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 11E093A6B0B for ; Thu, 10 Mar 2011 07:35:13 -0800 (PST) Received: by wwa36 with SMTP id 36so1449744wwa.13 for ; Thu, 10 Mar 2011 07:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KUZnV2tx00ZfmC9a/Y1YME6VMzuv4imH86znloRSc6g=; b=Bum6K4Ud9qb7W8vY8CdoDiu5zMfIFwWV2H9kMruDMCFhkT3YNUmsZNC7d0O7EveS5l RolzzZ6iamfXxesxlcC1ebt6YmWBet5ivMTelkWrgRndI6L1nwVnnF9PQ8w+u4W7Stj+ mLquU8ZiK3bvMTkEWEtlgHR9Ob5qo+N9QHCLs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NkViIEMptwjc0u7GUIUOm9bhQYZMzAqEWvtf/FCvDwDD22xioR6JbWLkKZTOntLtgk jIvEZj7dXM4YBM0GFrIiC6k5bkcHVPmDtQPlKWj7ZQJFojRpHCf7R3HrBI9vbbZ0ffFb kS++bvyPyfsTHjyJUoOcjDcKCdkRU54Ld+TSU= Received: by 10.227.195.75 with SMTP id eb11mr7227699wbb.120.1299771391251; Thu, 10 Mar 2011 07:36:31 -0800 (PST) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id w25sm2521136wbd.5.2011.03.10.07.36.29 (version=SSLv3 cipher=OTHER); Thu, 10 Mar 2011 07:36:30 -0800 (PST) Sender: Andy Green Message-ID: <4D78EFFD.5040906@warmcat.com> Date: Thu, 10 Mar 2011 15:36:29 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Pat McManus @Mozilla" References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <20110310103914.GA32389@1wt.eu> <1299769498.2606.252.camel@ds9.ducksong.com> In-Reply-To: <1299769498.2606.252.camel@ds9.ducksong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 15:35:15 -0000 On 03/10/2011 03:04 PM, Somebody in the thread at some point said: Hi - >> I suspect most would agree that masking of everything is better than >> stalling the protocol any longer, but if Adam is the only objector and >> the browser folks are okay with masking only payload then perhaps we >> should move forward with it. > > I object too. I think not masking the header gives up a minor security > benefit for an insubstantial benefit. None of the arguments about the It is much cleaner protocol-wise to have consistent framing and mask inside the extension area and allows server traffic masking to be selected the same way. Once that's done, if 4-byte recirculating xor with per-frame random key isn't enough, and we have been told it is not "enough" before if you recall, then it'll be easy to upgrade the protocol to use AES masking or whatever without breaking the framing. > benefits of the change have convinced me they add up to very much. To be fair these are mainly defending the idea of masking as a whole, by explaining that it is cheap --> > http://www.ietf.org/mail-archive/web/hybi/current/msg06689.html > http://www.ietf.org/mail-archive/web/hybi/current/msg06705.html > http://www.ietf.org/mail-archive/web/hybi/current/msg06718.html That's not really the issue, the issue is do we really impact these security concerns by letting what is often just two bytes but may extend to ten structured bytes with opcode + length in go out unmaksed. What in fact does your Mozilla implementation do about breaking large messages into CONTINUATION? As a sort of side note, since you have been supporting protecting these alleged vulnerable proxies, do you have any effort or interest in any effort to actively detect and identify them, maybe a fuzzing tool for content? It's curious there's so much handwringing about these alleged vulnerable intermediaries but actually I didn't see anyone give a toss about finding them until now. -Andy From jat@google.com Thu Mar 10 08:21:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BCEC3A6A1A for ; Thu, 10 Mar 2011 08:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.936 X-Spam-Level: X-Spam-Status: No, score=-105.936 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jibNflzVwt5t for ; Thu, 10 Mar 2011 08:21:51 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 78B8F3A69C3 for ; Thu, 10 Mar 2011 08:21:51 -0800 (PST) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p2AGN8EB004481 for ; Thu, 10 Mar 2011 08:23:08 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299774188; bh=fmCyiosF+bH2aOEIZegQZgi/WCE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=rc5vgOZZwRwYdXonVd0qVMkrTWWIqHo/ndL7OzgsBOx5745jS6Nw/jNX0He9CkyNR R8UDJ5paEzVb22l4b84pA== Received: from gxk2 (gxk2.prod.google.com [10.202.11.2]) by kpbe20.cbf.corp.google.com with ESMTP id p2AGMu5G007814 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 10 Mar 2011 08:23:07 -0800 Received: by gxk2 with SMTP id 2so938710gxk.0 for ; Thu, 10 Mar 2011 08:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=U8GQpaxcxexpgBThaPhhYcSzrS92oPopKnyK/JomZ7I=; b=GqMfhJWL68yyvcx3tjSRI+HU+Z1LoXloTmS01Laj+WXBawJj1SU+2k5CLE06R4gvDW aR5JpFilo6IPnMBL1lwA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=QxTjPAzZKh4d8mCx+2uity/kMx9q9wFxUrcnkwyh1dQSrwBniFe59gqWVA6J3tThMD 8ox5A0G5RBjai5VnOaPA== Received: by 10.150.209.1 with SMTP id h1mr1257063ybg.181.1299774187122; Thu, 10 Mar 2011 08:23:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Thu, 10 Mar 2011 08:22:47 -0800 (PST) In-Reply-To: <4D78EFFD.5040906@warmcat.com> References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <20110310103914.GA32389@1wt.eu> <1299769498.2606.252.camel@ds9.ducksong.com> <4D78EFFD.5040906@warmcat.com> From: John Tamplin Date: Thu, 10 Mar 2011 11:22:47 -0500 Message-ID: To: Andy Green Content-Type: multipart/alternative; boundary=000e0cd51c9eb634ea049e234214 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 16:21:53 -0000 --000e0cd51c9eb634ea049e234214 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 10, 2011 at 10:36 AM, Andy Green wrote: > It is much cleaner protocol-wise to have consistent framing and mask inside > the extension area and allows server traffic masking to be selected the same > way. > While I agree it is awkward to not be able to have a totally separate layer where the masking is removed (since you can't know the length of the masked frames without looking inside the masking), I don't think anyone is going to implement it that way. Instead, what will happen is that a flag will be passed in saying to expect a mask, and it is just as easy to read that mask before the opcode/length as it is afterwards (whether doing it with blocking reads or a state machine for processing the next available bytes). So, I don't really see how it makes much difference from an implementation point of view. Once that's done, if 4-byte recirculating xor with per-frame random key > isn't enough, and we have been told it is not "enough" before if you recall, > then it'll be easy to upgrade the protocol to use AES masking or whatever > without breaking the framing. I don't see a difference here either -- if in the future a more sophisticated masking is required, an extension would be negotiated that will change it. Browsers could choose to drop connections if the server didn't accept this extension after some transition period, and then the new masking algorithm would be applied to what was going on the wire. If you wanted to support both, it is easy enough for that boolean flag to become an enum specifying the type of masking to be applied. Regarding the negative impact of masking outside the framing, remember it is only transparent intermediaries we are worried about (which includes packet sniffers) since they can only observe the handshake but can't participate in it. Thus, if an extension is negotiated they don't understand, they can't do anything with the stream. I don't see there is much that can be done about it -- for example, imagine the deflate-stream extension in -06 was not part of the standard but a later extension. No intermediary would even be able to find frame boundaries if they didn't understand the extension. As for using wireshark/etc to debug it, a simple heuristic like looking at the port should get 95% of it right, and the user can always force interpretation as WebSocket-client or WebSocket-server if they don't capture the handshake. Other intermediaries that must operate independently (such as sniffers enforcing policy) are going to have to see the handshake to do their job, and they have to already distinguish WebSocket traffic from others in order to do their job, and in the process they will know which side they are looking at. So, my position is that I am unconvinced of the benefits of moving the mask after the opcode/length, but I also think the additional risk exposed by doing so is minimal, so I don't feel to strongly about it. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd51c9eb634ea049e234214 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 10, 2011 at 10:36 AM, Andy Green <andy@warmcat.com= > wrote:
It is much cleaner protocol-wise to have consistent frami= ng and mask inside the extension area and allows server traffic masking to = be selected the same way.

While I agr= ee it is awkward to not be able to have a totally separate layer where the = masking is removed (since you can't know the length of the masked frame= s without looking inside the masking), I don't think anyone is going to= implement it that way. =C2=A0Instead, what will happen is that a flag will= be passed in saying to expect a mask, and it is just as easy to read that = mask before the opcode/length as it is afterwards (whether doing it with bl= ocking reads or a state machine for processing the next available bytes). = =C2=A0So, I don't really see how it makes much difference from an imple= mentation point of view.

Once that's done, if 4-byte recirculating xor with per-frame random key= isn't enough, and we have been told it is not "enough" befor= e if you recall, then it'll be easy to upgrade the protocol to use AES = masking or whatever without breaking the framing.

I don't see a difference here either -- if in the f= uture a more sophisticated masking is required, an extension would be negot= iated that will change it. =C2=A0Browsers could choose to drop connections = if the server didn't accept this extension after some transition period= , and then the new masking algorithm would be applied to what was going on = the wire. =C2=A0If you wanted to support both, it is easy enough for that b= oolean flag to become an enum specifying the type of masking to be applied.=

Regarding the negative impact of masking outside the fr= aming, remember it is only transparent intermediaries we are worried about = (which includes packet sniffers) since they can only observe the handshake = but can't participate in it. =C2=A0Thus, if an extension is negotiated = they don't understand, they can't do anything with the stream. =C2= =A0I don't see there is much that can be done about it -- for example, = imagine the deflate-stream extension in -06 was not part of the standard bu= t a later extension. =C2=A0No intermediary would even be able to find frame= boundaries if they didn't understand the extension.

As for using wireshark/etc to debug it, a simple heuris= tic like looking at the port should get 95% of it right, and the user can a= lways force interpretation as WebSocket-client or WebSocket-server if they = don't capture the handshake. =C2=A0Other intermediaries that must opera= te independently (such as sniffers enforcing policy) are going to have to s= ee the handshake to do their job, and they have to already distinguish WebS= ocket traffic from others in order to do their job, and in the process they= will know which side they are looking at.

So, my position is that I am unconvinced of the benefit= s of moving the mask after the opcode/length, but I also think the addition= al risk exposed by doing so is minimal, so I don't feel to strongly abo= ut it.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd51c9eb634ea049e234214-- From mcmanus@ducksong.com Thu Mar 10 08:28:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C67943A6B2E for ; Thu, 10 Mar 2011 08:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly7Nk-O-3DrW for ; Thu, 10 Mar 2011 08:28:13 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 004513A6A3E for ; Thu, 10 Mar 2011 08:28:12 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id 4D2AF102A6; Thu, 10 Mar 2011 11:29:30 -0500 (EST) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 1C51410159; Thu, 10 Mar 2011 11:29:26 -0500 (EST) From: Patrick McManus To: Andy Green In-Reply-To: <4D78EFFD.5040906@warmcat.com> References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <20110310103914.GA32389@1wt.eu> <1299769498.2606.252.camel@ds9.ducksong.com> <4D78EFFD.5040906@warmcat.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Mar 2011 11:29:43 -0500 Message-ID: <1299774583.2606.266.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 16:28:13 -0000 On Thu, 2011-03-10 at 15:36 +0000, Andy Green wrote: > > I object too. I think not masking the header gives up a minor security > It is much cleaner protocol-wise to have consistent framing and mask The point of my message this morning was to make my opinion clear as it seemingly had been missed or misunderstood. You don't need to make the same arguments again - I'm not trying to argue mine again - simply show that they were argued. > What in fact does your Mozilla implementation do about breaking large > messages into CONTINUATION? for a variety of reasons right now it does not generate fragments. Though I am considering changing that based on operational experience. From jat@google.com Thu Mar 10 08:30:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4C23A6A3A for ; Thu, 10 Mar 2011 08:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.824 X-Spam-Level: X-Spam-Status: No, score=-105.824 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXXwd-uuMqbZ for ; Thu, 10 Mar 2011 08:30:21 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id CCF8A3A6A1A for ; Thu, 10 Mar 2011 08:30:20 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p2AGVbk3014796 for ; Thu, 10 Mar 2011 08:31:37 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299774698; bh=dIk9Ku1DM0eaBWxgTtv6tY2UgY4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=H7F2HMQB78JsXQ1HepOCmbbDtVZUNX0mGzckSe2Piqw67ceHmvxIVB6RLFrskB0SF Pd2kxQKyQQ64nYRXopttg== Received: from yia27 (yia27.prod.google.com [10.243.65.27]) by wpaz21.hot.corp.google.com with ESMTP id p2AGUeMC021604 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 10 Mar 2011 08:31:36 -0800 Received: by yia27 with SMTP id 27so836110yia.33 for ; Thu, 10 Mar 2011 08:31:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GA92UaFbd9p2gIYpAxCgg2ouWOOxHB2TL3/VgBPS0nU=; b=fGApwwpewi8L6Gii7sGTLscYoK4vFst5FAyCXidMecTfFaXN67Dfblkug22S5dYRT1 0YXiUz6qzpx/G6QUsmLg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=oDSjtFTFvW97RSZNA5oKU+g9BbzaR7lLtQQQB6esMOHRTxqujtFELo7Wq4Lwb5AhfK dLaY0NB6KkzLHz0i4AUA== Received: by 10.151.157.9 with SMTP id j9mr1244285ybo.409.1299774696157; Thu, 10 Mar 2011 08:31:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Thu, 10 Mar 2011 08:31:16 -0800 (PST) In-Reply-To: References: <4D77FB84.9010104@warmcat.com> <4D789223.8010208@warmcat.com> <4D78C12C.1080108@warmcat.com> From: John Tamplin Date: Thu, 10 Mar 2011 11:31:16 -0500 Message-ID: To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=001517510fdc0d72cb049e236136 X-System-Of-Record: true Cc: hybi@ietf.org, Yutaka_Takeda@playstation.sony.com Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 16:30:22 -0000 --001517510fdc0d72cb049e236136 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 10, 2011 at 7:34 AM, Takeshi Yoshino wrote: > OK. So we can add an implementation note like this. > > Senders using this extension MUST apply RFC 1951 DEFLATE to all the bytes >> of the application data portion of data frames. Senders MAY include multiple >> blocks in a frame. Senders MAY use blocks of any type as defined in RFC >> 1951. Senders MUST use the algorithm described in Section 2.1 of RFC1979 to >> align compressed data to byte boundary. Senders MAY keep using the same LZ77 >> sliding window for multiple frames. > > > If you're using zlib for applying DEFLATE compression, specify Z_SYNC_FLUSH > when you flush the last octets of application data for each frame (in case > the last block is non-compressed block (BTYPE=00), append one empty > compressed block (BTYPE=01)), and then strip the last 4 octets from the > compressed octets. > > Receivers MUST append 0x00 0x00 0xff 0xff to the application data portion >> and decompress it using DEFLATE to decode the original application data. >> Receivers MUST keep using the same LZ77 sliding window for all the frames of >> the same WebSocket connection. Receivers MUST assume the senders use 32768 >> byte LZ77 sliding window. > > > If you're using zlib for applying DEFLATE compression, for each received > frame, concatenate 4 octets 0x00 0x00 0xff 0xff and the application data, > and then supply the resulting bytes to zlib and use the uncompressed data. > zlib is just one implementation, and I don't think the spec should be choosing one implementation instead of the algorithm. Therefore, we shouldn't be using zlib-specific terminology in the spec. I don't object to compressing only the payload (though it does make implementations more complicated, rather than just pushing a compressor/decompressor onto the stream having to switch back and forth), but couldn't the issue we are trying to solve here be done by just saying that if deflate-stream is negotiated and a close frame is read, you cannot initiate close processing until the final compressed block is read completely? In any case, I think deflate-stream is only a stop-gap solution to get some form of compression in the spec, also serving as an example extension. I think realistically we are going to have to have the ability to avoid compressing incompressible data in the stream. Initially, where WebSockets implementations only support plain text, this won't be much of a problem, but eventually clients will be mixing binary data with their text and we would prefer to be able to use compression where it helps and not use it where it hurts. -- John A. Tamplin Software Engineer (GWT), Google --001517510fdc0d72cb049e236136 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 10, 2011 at 7:34 AM, Takeshi Yoshino= <tyoshino@goog= le.com> wrote:
OK. So we can = add an implementation note like this.

=
Senders using this extension MUST apply RFC 1951 DEFLATE to all the bytes o= f the application data portion of data frames. Senders MAY include multiple= blocks in a frame. Senders MAY use blocks of any type as defined in RFC 19= 51. Senders MUST use the algorithm described in Section 2.1 of RFC1979 to a= lign compressed data to byte boundary. Senders MAY keep using the same LZ77= sliding window for multiple frames.

If you're using zlib for applying DEFLATE compressi= on, specify Z_SYNC_FLUSH when you flush the last octets of application data= for each frame (in case the last block is non-compressed block (BTYPE=3D00= ), append one empty compressed block (BTYPE=3D01)), and then strip the last= 4 octets from the compressed octets.

Subject: Re: [hybi] Fwd: New Version Notification for draft-thomson-hybi-http-timeout-00 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 17:38:17 -0000 Hey, A couple of thoughts -- I regularly am asked by devs for something like Request-Timeout, usually = for enforcement on an intermediary, rather than the origin, but it's = applicable there too. I always resist it, because there's a race condition between the = client's declared request time and its enforcement (as you know it). = It's better to just close the connection and enforce the timeout where = it's declared; no matter how clearly you document that this is just = advisory, many developers will look at request-timeout and immediately = use it in place of a client-side timeout.=20 Do you have use cases for Request-Timeout that aren't covered by a = client-side timeout? Regarding Connection-Timeout - I still think a simple indication that = it's a long-lived request is more useful (and truthful), but if you are = going to go down this road, you'll need to define 'idle' more carefully.=20= For example, Squid had the concept of a read timeout = , = which applies to connections with an outstanding request on them, but it = also has a persistent request timeout = which applies to those that don't. How do they interact = with Connection-TImeout? Cheers,=09 On 09/03/2011, at 3:37 AM, Salvatore Loreto wrote: > (as individual) >=20 >=20 > Martin, Greg and I have submitted the following draft: > http://tools.ietf.org/id/draft-thomson-hybi-http-timeout-00.txt >=20 > The draft only defines HTTP headers that can be (re)used for discovery = idle time to use in > both LongPolling/Comet and WebSocket connection lifetime management = (keep alive process). >=20 > Note, the draft does not discuss the actual WebSocket keep alive = process; > and this thread is only to discuss the mechanism for discovery idle = time. >=20 >=20 > Comments and opinions on the draft are very welcome and appreciate. >=20 > cheers > /Sal >=20 > --=20 > Salvatore Loreto >=20 > www.sloreto.com >=20 >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for = draft-thomson-hybi-http-timeout-00 > Date: Mon, 7 Mar 2011 00:09:52 +0100 > From: IETF I-D Submission Tool > To: martin.thomson@andrew.com > CC: Salvatore Loreto , = "gregw@intalio.com" >=20 > A new version of I-D, draft-thomson-hybi-http-timeout-00.txt has been = successfully submitted by Martin Thomson and posted to the IETF = repository. >=20 > Filename: draft-thomson-hybi-http-timeout > Revision: 00 > Title: Hypertext Transfer Protocol (HTTP) Timeouts > Creation_date: 2011-03-07 > WG ID: Independent Submission > Number_of_pages: 12 >=20 > Abstract: > A Request-Timeout header is defined for Hypertext Transfer Protocol > (HTTP). This end-to-end header informs an origin server and any > intermediaries of the maximum time that a client will await a > response to its request. A server can use this header to ensure that > a timely response is generated. This also identifies requests as > being potentially long-lived, and allows for better resource > allocation for these requests. >=20 > A Connection-Timeout header is defined for HTTP. This hop-by-hop > header informs the entity at the other end of a connection of the > maximum time that an idle connection is kept open. This header > improves reliability by providing better information about the idle > connection management policy of HTTP hosts. > = =20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi -- Mark Nottingham http://www.mnot.net/ From bruce@callenish.com Thu Mar 10 10:17:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE663A68CB for ; Thu, 10 Mar 2011 10:17:26 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYRQ5C5QQDLt for ; Thu, 10 Mar 2011 10:17:26 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 03AFA3A67EE for ; Thu, 10 Mar 2011 10:17:26 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.103]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1PxkRf-00081f-1S; Thu, 10 Mar 2011 10:18:43 -0800 Message-ID: <4D7915FF.50300@callenish.com> Date: Thu, 10 Mar 2011 10:18:39 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 18:17:26 -0000 Are we voting on this now? If so, add my +1 for the proposal not to mask the framing. On 10/03/2011 2:25 AM, Brian wrote: > By my count, we have six voices in favor so far, including myself: > Andy Green > Ytaka Takeda > Greg Wilkins > Willy Tarreau > Joel Martin > Brian McKelvey > > One on record as not having a strong opinion one way or the other: > Ian Fette > > And one opposed: > Adam Barth > > From julian.reschke@gmx.de Thu Mar 10 10:31:43 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043D53A6A84 for ; Thu, 10 Mar 2011 10:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.83 X-Spam-Level: X-Spam-Status: No, score=-103.83 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUbf7H4CPfUD for ; Thu, 10 Mar 2011 10:31:42 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id B015E3A68F5 for ; Thu, 10 Mar 2011 10:31:41 -0800 (PST) Received: (qmail invoked by alias); 10 Mar 2011 18:32:57 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.134]) [217.91.35.233] by mail.gmx.net (mp059) with SMTP; 10 Mar 2011 19:32:57 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+1ZPBhzG+1PKyXPBCOzqtizoPcDo6Vzi2eYjSNEf YqDf5RuWFeBqT7 Message-ID: <4D791954.2070306@gmx.de> Date: Thu, 10 Mar 2011 19:32:52 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Bruce Atherton References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> In-Reply-To: <4D7915FF.50300@callenish.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 18:31:43 -0000 On 10.03.2011 19:18, Bruce Atherton wrote: > Are we voting on this now? If so, add my +1 for the proposal not to mask > the framing. > ... No, we don't. (see ) Best regards, Julian PS: that being said, I support the proposal not to mask the framing data. From dendicott@gmail.com Thu Mar 10 10:32:01 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBDE83A6B58 for ; Thu, 10 Mar 2011 10:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kx+4XBaNwbz5 for ; Thu, 10 Mar 2011 10:32:01 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id A92443A67EE for ; Thu, 10 Mar 2011 10:32:00 -0800 (PST) Received: by wwa36 with SMTP id 36so1606207wwa.13 for ; Thu, 10 Mar 2011 10:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sn3OhIKvewH6SYq8WJqZO+8CtAwNo33sVMqJsAo+kHw=; b=KIn9xK0gEsNbTB97/yNw6iansDGSa/gKO7Uf7QUuDwaTGLraySHOaXst7oik/GuiH1 p3W+78gSkKFVo7+shznAM7kFqNPQKbHCPz/9yx+3Q/xOxz/zHE7/KJbxKWsCHTkjLy6J HrEMy7EpObn/JRFwE2ikoxsb7d5CjaBBEMvtg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RHDHrE79TaU1mF7dhSroKcJ1nqCXkOhzqd5jqSfWMIsUr77cTIvQqKpbzaMysmyfTc i/TST7Cj1X+70DkJmMxGHWGmefzJNyn1nskqm4nVe+qYTTYGEWub5iCCPkcciO7amUI4 fpmLsvVc6cCSlSfIn5+TGzP/6wAf63R1pGBQw= MIME-Version: 1.0 Received: by 10.216.246.12 with SMTP id p12mr6804549wer.91.1299781997959; Thu, 10 Mar 2011 10:33:17 -0800 (PST) Received: by 10.216.122.13 with HTTP; Thu, 10 Mar 2011 10:33:17 -0800 (PST) In-Reply-To: <4D7915FF.50300@callenish.com> References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> Date: Thu, 10 Mar 2011 13:33:17 -0500 Message-ID: From: David Endicott To: Bruce Atherton Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 18:32:01 -0000 Count me in as +1 in favour of no masking. My reasoning being: 1. An application layer using a Websocket API cannot affect the headers, only payload. 2. The Websocket connection is an *established* TCP connection that has already navigated any intermediaries and satisfied their connection requirements. 3. If these intermediaries choose to examine the data being passed through this established connection, then it is their problem if they expose themselves. 4. This alleged intermediary vulnerability would be available via any mal-formed stream, if the intermediary is doing content examination. 5. Masking does not prevent man-in-the-middle attacks as the masking key is included with the frame. 6. Agents that open a bare TCP connection and emulate Websocket allow the attacker to craft custom frames or handshakes. They can of course generate whatever end-result masking they need. So, I conclude that masking does not protect against (a) man-in-the-middle or (b) a malicious application layer, or (c) attack application. Further, since the initial HTTP Upgrade handshake negotiates connection establishment via any intermediary (satisfies proxies, etc.), we must feel free to transmit any data content without worrying we would disturb any hops between endpoints. That is fundamental to the definition of transparent intermediary. On Thu, Mar 10, 2011 at 1:18 PM, Bruce Atherton wrote: > Are we voting on this now? If so, add my +1 for the proposal not to mask the > framing. > > On 10/03/2011 2:25 AM, Brian wrote: >> >> By my count, we have six voices in favor so far, including myself: >> Andy Green >> Ytaka Takeda >> Greg Wilkins >> Willy Tarreau >> Joel Martin >> Brian McKelvey >> >> One on record as not having a strong opinion one way or the other: >> Ian Fette >> >> And one opposed: >> Adam Barth >> >> > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From jat@google.com Thu Mar 10 10:51:47 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BBBA3A6942 for ; Thu, 10 Mar 2011 10:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.828 X-Spam-Level: X-Spam-Status: No, score=-105.828 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyOoAPtzCzxp for ; Thu, 10 Mar 2011 10:51:46 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id F041C3A68DC for ; Thu, 10 Mar 2011 10:51:45 -0800 (PST) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p2AIr2Mh017204 for ; Thu, 10 Mar 2011 10:53:03 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299783183; bh=9hQkJebJn6EyJJMdeDuHQUJK7JQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=gzduK20BjgIrUc0y3In5Hw4vJ+MBBHDMH37rPaAquWPmNVL0I/reLZ3s1kQeLklbK tJwP/8UWljbOOQ0vFH0Ow== Received: from gwb20 (gwb20.prod.google.com [10.200.2.20]) by kpbe20.cbf.corp.google.com with ESMTP id p2AIr1pF014633 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 10 Mar 2011 10:53:01 -0800 Received: by gwb20 with SMTP id 20so599655gwb.3 for ; Thu, 10 Mar 2011 10:53:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4QqhNjliEAtaYd0BkJu76CthimpH9KxzdfgsOMx3xEo=; b=G7P6GOPik+HQ0bhYIk2MuqIVktVoeuweTMa83o9DZvEWR9lq5V++6QgdQF9AF+85k5 Mb5MYKBqpAzKF7HwjWbw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=ntm0SZoqKuch9ua1HCZggclgsVVven1d/1Mjwf9+e4zLAf584l1hPXNwywRENsjkAK BEVUMjVEGsqKLlBcd2xA== Received: by 10.151.157.9 with SMTP id j9mr1409738ybo.409.1299783181124; Thu, 10 Mar 2011 10:53:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Thu, 10 Mar 2011 10:52:41 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> From: John Tamplin Date: Thu, 10 Mar 2011 13:52:41 -0500 Message-ID: To: David Endicott Content-Type: multipart/alternative; boundary=001517510fdccbc3fd049e255a1b X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 18:51:47 -0000 --001517510fdccbc3fd049e255a1b Content-Type: text/plain; charset=UTF-8 On Thu, Mar 10, 2011 at 1:33 PM, David Endicott wrote: > Count me in as +1 in favour of no masking. > We declared consensus long ago that we would require masking on client->server. Your points below are nothing that wasn't brought up before that decision, so I don't see why we should revisit it. This discussion is about whether to have the mask before or after the opcode/length fields in the frame. -- John A. Tamplin Software Engineer (GWT), Google --001517510fdccbc3fd049e255a1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 10, 2011 at 1:33 PM, David Endicott = <dendicott@gmai= l.com> wrote:
Count me in as +1 in favour of no masking.

<= div>We declared consensus long ago that we would require masking on client-= >server. =C2=A0Your points below are nothing that wasn't brought up = before that decision, so I don't see why we should revisit it.

This discussion is about whether to have the mask befor= e or after the opcode/length fields in the frame.

--
Joh= n A. Tamplin
Software Engineer (GWT), Google
--001517510fdccbc3fd049e255a1b-- From bruce@callenish.com Thu Mar 10 10:57:32 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A58F3A692A for ; Thu, 10 Mar 2011 10:57:32 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqWLoILuL+fD for ; Thu, 10 Mar 2011 10:57:31 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 782FB3A6923 for ; Thu, 10 Mar 2011 10:57:31 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.103]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pxl4Q-0001Qh-Up; Thu, 10 Mar 2011 10:58:47 -0800 Message-ID: <4D791F64.4030107@callenish.com> Date: Thu, 10 Mar 2011 10:58:44 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Julian Reschke References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> <4D791954.2070306@gmx.de> In-Reply-To: <4D791954.2070306@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 18:57:32 -0000 On 10/03/2011 10:32 AM, Julian Reschke wrote: > On 10.03.2011 19:18, Bruce Atherton wrote: >> Are we voting on this now? If so, add my +1 for the proposal not to mask >> the framing. >> ... > > No, we don't. > > (see ) I didn't mean a vote to determine which way to go on the proposal, I meant another straw poll to indicate whether there is rough consensus. If we are adding up numbers of people arguing one way or another, that feels like a straw poll to me. It seems like a good time for one anyway. There seem to be three schools of thought: those who feel there are costs to masking the framing that should be avoided given the minimal benefits; those who feel there are no costs to masking the framing and so no reason to lose the minimal benefits; and those who believe that the benefits are not minimal and should trump any of the costs. I don't see any of those positions changing any time soon, no matter how much further discussion there is. The only question now is whether rough consensus has been reached one way or another. OTOH, perhaps the chairs have already determined that there is a rough consensus and a poll is not needed. > > > Best regards, Julian > > PS: that being said, I support the proposal not to mask the framing data. From dendicott@gmail.com Thu Mar 10 11:07:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F117E3A6826 for ; Thu, 10 Mar 2011 11:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3UvImR6fovA for ; Thu, 10 Mar 2011 11:07:27 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id A6D533A6B46 for ; Thu, 10 Mar 2011 11:07:22 -0800 (PST) Received: by wyb42 with SMTP id 42so1994288wyb.31 for ; Thu, 10 Mar 2011 11:08:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OQjphXKVrizhGdLH20maZfjDWtqLcZUS91og/0O4r50=; b=r76nVJwYPNHvHb0R+w6EWw5xIEHI3LTaWKWytRbdxNUTufxVM7mpkh7mo5n9f+hOUi cz4/z/v3fLZJiHX+pP1H0Zi8YoSlZBEI5MHQmmq0r1IXZkEuhdNbIFyht21WHtVs+fnn nXUEoLNXCmpmnjC1NmaOuDwm8uFYyHcHD+L4Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xz+geXj8tgF4W5w+l0nemgvBzT472aeHWd4+erX208Wa1FathJAk7pMxM5+Brxun+S 7+J+++E07SQRJAj05sViX3L32dn861U3/eabZhAi7eSXG9hGw7EWYwEHOw5HJBcQqLJf TQxRVqEdIDCiFBPl5mPYgaDTjHqm4VupEEHQ4= MIME-Version: 1.0 Received: by 10.216.242.131 with SMTP id i3mr6818687wer.106.1299784120271; Thu, 10 Mar 2011 11:08:40 -0800 (PST) Received: by 10.216.122.13 with HTTP; Thu, 10 Mar 2011 11:08:40 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> Date: Thu, 10 Mar 2011 14:08:40 -0500 Message-ID: From: David Endicott To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 19:07:28 -0000 Sorry, I misunderstood the context of the conversation. It would seem to me that it must go after the length field, or else how does the server know how much of the following stream to unmask. It would need to unmask enough of the header to determine the entire frame size and then continue. That seems an unnecessary burden and complicates server reception processing. +1 for masking (as silly as it is) after the header. On Thu, Mar 10, 2011 at 1:52 PM, John Tamplin wrote: > On Thu, Mar 10, 2011 at 1:33 PM, David Endicott wro= te: >> >> Count me in as +1 in favour of no masking. > > We declared consensus long ago that we would require masking on > client->server. =A0Your points below are nothing that wasn't brought up b= efore > that decision, so I don't see why we should revisit it. > This discussion is about whether to have the mask before or after the > opcode/length fields in the frame. > -- > John A. Tamplin > Software Engineer (GWT), Google > From jat@google.com Thu Mar 10 11:12:30 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F011C3A686C for ; Thu, 10 Mar 2011 11:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.832 X-Spam-Level: X-Spam-Status: No, score=-105.832 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D862uC1rmRU1 for ; Thu, 10 Mar 2011 11:12:29 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 836053A6826 for ; Thu, 10 Mar 2011 11:12:28 -0800 (PST) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p2AJDkHg001490 for ; Thu, 10 Mar 2011 11:13:46 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299784426; bh=y2t02HlFWOtiFZLJp6E3utMnRFw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=BdQG67YYfL9+6MuQyMGetbC+zvXCIb+fXjOxXZx1cg8sZPtBPIVpBnAw1PCOdHaTQ bUd3TQRPnmnVSucxl5IRg== Received: from gwj15 (gwj15.prod.google.com [10.200.10.15]) by hpaq12.eem.corp.google.com with ESMTP id p2AJDiTH004433 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 10 Mar 2011 11:13:45 -0800 Received: by gwj15 with SMTP id 15so1289159gwj.25 for ; Thu, 10 Mar 2011 11:13:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ciqxPe3lomzR6bGnuFbVHlEzNdBiCPa8G6z9dQBGpto=; b=VPplZbERZ4BpJgMW1yEGDxkEw9mdHrv1Dq+qQJyXCuhoX8iZdEP2oz1Uc8C5ti/z11 C1EZ9Pm1rHYTHWW/WVaA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=FYIfMBhABOqw80cZ+j+oOWglSCra6YHCF1BDNaIPApJI1A7OkkTYFlSsbvKnUjJSlv +NVoZ+E4/7a0LgulsS5A== Received: by 10.150.170.19 with SMTP id s19mr1472293ybe.67.1299784424084; Thu, 10 Mar 2011 11:13:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Thu, 10 Mar 2011 11:13:24 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> From: John Tamplin Date: Thu, 10 Mar 2011 14:13:24 -0500 Message-ID: To: David Endicott Content-Type: multipart/alternative; boundary=000e0cd4cc3ce1d59a049e25a4b1 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 19:12:31 -0000 --000e0cd4cc3ce1d59a049e25a4b1 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 10, 2011 at 2:08 PM, David Endicott wrote: > It would seem to me that it must go after the length field, or else > how does the server know how much of the following stream to unmask. > It would need to unmask enough of the header to determine the entire > frame size and then continue. That seems an unnecessary burden and > complicates server reception processing. > I'm not sure I understand your objection. If you are writing a blocking implementation, in the unmasked case you are going to read 2 bytes, and then look at the second byte to decide how many more bytes are in the header. That lets you determine the length of the frame and read the rest of it. In the masked case, (as implemented in -06) you will read 6 bytes, then start applying the mask to the bytes read as you process them. In the non-blocking case, you will have a state machine keeping track of where you are, and as you receive a byte after you have processed the mask you unmask it and process it. I don't see that it adds much complexity. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd4cc3ce1d59a049e25a4b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 10, 2011 at 2:08 PM, David Endicott = <dendicott@gmai= l.com> wrote:
It would seem to me that it must go after the length field, or else
how does the server know how much of the following stream to unmask.
It would need to unmask enough of the header to determine the entire
frame size and then continue. =C2=A0That seems an unnecessary burden and complicates server reception processing.

I'm not sure I understand your objection. =C2=A0If you are writing a = blocking implementation, in the unmasked case you are going to read 2 bytes= , and then look at the second byte to decide how many more bytes are in the= header. =C2=A0That lets you determine the length of the frame and read the= rest of it. =C2=A0In the masked case, (as implemented in -06) you will rea= d 6 bytes, then start applying the mask to the bytes read as you process th= em. =C2=A0In the non-blocking case, you will have a state machine keeping t= rack of where you are, and as you receive a byte after you have processed t= he mask you unmask it and process it. =C2=A0I don't see that it adds mu= ch complexity.
=C2=A0
--
John A. Tamplin
Software Engineer (GWT), G= oogle
--000e0cd4cc3ce1d59a049e25a4b1-- From dendicott@gmail.com Thu Mar 10 11:28:37 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5BE3A68B1 for ; Thu, 10 Mar 2011 11:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8RrFBXu1IlY for ; Thu, 10 Mar 2011 11:28:36 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B15FD3A6826 for ; Thu, 10 Mar 2011 11:28:35 -0800 (PST) Received: by wwa36 with SMTP id 36so1651519wwa.13 for ; Thu, 10 Mar 2011 11:29:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hik55uaQwB7RWYSnDlvgsi2fsYVJ8TDa+6Mp9rTBuDw=; b=YHO8G39QJIydlHPa+8jOSD7tM5ECx0HkiipKPiGFMQsm6Sp3i107lbIK5KQVqtSQIR kDIuU7CBwVkSa4MTxZsqrtDO6FmpXj8G6d4B1wWPV+NehLYYRpuFeH++c7ow3ahjrK5X +wW+9QYJjMv3k6wzConIvMGc7lrA6ff834nVg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=c8OoyrIcRx80aMQ/psWpQwv5UmMt1h8oWjuJ8vG3JOMI+/UKByi8DPkIO//SMxypbV um33XmjNLqaWzhAVSBd7wguKUHbDjiESaCjJ8BBFM1AFMzJQ08TpZEewrddMnYfBAK5A O0TeqknDUCokE/ixN18Ew1DZ+Q6FjnMZNUIGE= MIME-Version: 1.0 Received: by 10.216.190.131 with SMTP id e3mr6941629wen.76.1299785392808; Thu, 10 Mar 2011 11:29:52 -0800 (PST) Received: by 10.216.122.13 with HTTP; Thu, 10 Mar 2011 11:29:52 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> Date: Thu, 10 Mar 2011 14:29:52 -0500 Message-ID: From: David Endicott To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 19:28:38 -0000 Fair point. I agree it is not an undue burden given that we already have to deal with variable sized length fields anyway. Upon reflection, I change my vote to: don't care. I cannot see an obvious benefit or drawback to either implementation. On Thu, Mar 10, 2011 at 2:13 PM, John Tamplin wrote: > On Thu, Mar 10, 2011 at 2:08 PM, David Endicott wro= te: >> >> It would seem to me that it must go after the length field, or else >> how does the server know how much of the following stream to unmask. >> It would need to unmask enough of the header to determine the entire >> frame size and then continue. =A0That seems an unnecessary burden and >> complicates server reception processing. > > I'm not sure I understand your objection. =A0If you are writing a blockin= g > implementation, in the unmasked case you are going to read 2 bytes, and t= hen > look at the second byte to decide how many more bytes are in the header. > =A0That lets you determine the length of the frame and read the rest of i= t. > =A0In the masked case, (as implemented in -06) you will read 6 bytes, the= n > start applying the mask to the bytes read as you process them. =A0In the > non-blocking case, you will have a state machine keeping track of where y= ou > are, and as you receive a byte after you have processed the mask you unma= sk > it and process it. =A0I don't see that it adds much complexity. > > -- > John A. Tamplin > Software Engineer (GWT), Google > From dendicott@gmail.com Thu Mar 10 11:35:27 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79EDF3A6826 for ; Thu, 10 Mar 2011 11:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJRBgdeH7KhP for ; Thu, 10 Mar 2011 11:35:26 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 236AE3A68B1 for ; Thu, 10 Mar 2011 11:35:25 -0800 (PST) Received: by wyb42 with SMTP id 42so2021084wyb.31 for ; Thu, 10 Mar 2011 11:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=16+eZG5+Lu3HFNIRVWCw2cB2+aTgZB99GoHyvsq1PBo=; b=DZjSgebZfXmhvVvfUDBXlf1MterRSD7MpDwSIuZNJDSSWdyPS8Novh/n0LyvyXJInH +8+dZKKMO9OfszJRKyacJT6e8SQo3AUGU2BImEj+mWJR1usVc/WlKfXugADd7QH/qeAh m0RgMmnA/h1rwtedAC4W+vfAsBLVf3u75WOaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QTh86WRNEVvIZyk9pek5zMfDJnT7KiDUBtRWjgHzM8/jP6mhN7HjUv+ur+CgBLnkaI fgjQmAL5OG6j+z381ys/No8pu93n0ft4NPeNwsEXmy+efymqQWrGRA/FIKCbAbKpsGot 33ZN0CEUgsP3YBv5vQU6XA3EJNp8vODwAuEr4= MIME-Version: 1.0 Received: by 10.216.171.133 with SMTP id r5mr6012935wel.91.1299785803587; Thu, 10 Mar 2011 11:36:43 -0800 (PST) Received: by 10.216.122.13 with HTTP; Thu, 10 Mar 2011 11:36:43 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> Date: Thu, 10 Mar 2011 14:36:43 -0500 Message-ID: From: David Endicott To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 19:35:27 -0000 Afterthought: an unmasked header would allow Websocket aware intermediaries to manipulate frames without unmasking them. Websocket aware load balancers and distributed frameworks come to mind. On Thu, Mar 10, 2011 at 2:29 PM, David Endicott wrote= : > Fair point. =A0I agree it is not an undue burden given that we already > have to deal with variable sized length fields anyway. > > Upon reflection, I change my vote to: don't care. =A0 =A0I cannot see an > obvious benefit or drawback to either implementation. > > > > On Thu, Mar 10, 2011 at 2:13 PM, John Tamplin wrote: >> On Thu, Mar 10, 2011 at 2:08 PM, David Endicott wr= ote: >>> >>> It would seem to me that it must go after the length field, or else >>> how does the server know how much of the following stream to unmask. >>> It would need to unmask enough of the header to determine the entire >>> frame size and then continue. =A0That seems an unnecessary burden and >>> complicates server reception processing. >> >> I'm not sure I understand your objection. =A0If you are writing a blocki= ng >> implementation, in the unmasked case you are going to read 2 bytes, and = then >> look at the second byte to decide how many more bytes are in the header. >> =A0That lets you determine the length of the frame and read the rest of = it. >> =A0In the masked case, (as implemented in -06) you will read 6 bytes, th= en >> start applying the mask to the bytes read as you process them. =A0In the >> non-blocking case, you will have a state machine keeping track of where = you >> are, and as you receive a byte after you have processed the mask you unm= ask >> it and process it. =A0I don't see that it adds much complexity. >> >> -- >> John A. Tamplin >> Software Engineer (GWT), Google >> > From jat@google.com Thu Mar 10 11:48:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52813A67FF for ; Thu, 10 Mar 2011 11:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.836 X-Spam-Level: X-Spam-Status: No, score=-105.836 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ze3sucL4aUwE for ; Thu, 10 Mar 2011 11:48:33 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 890913A6811 for ; Thu, 10 Mar 2011 11:48:33 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p2AJnoEC032517 for ; Thu, 10 Mar 2011 11:49:50 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299786591; bh=Vjv/lP57bhU97LvCga64GmoZ2qw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=SBhKP68sORmhRzpEvKAAg3RdikuRRxeziEGd1rXX+GC8EoK4Mob4O7Mum4yUtKVHc ZeOFJvJsOO5JX8dkYUKcQ== Received: from gyg13 (gyg13.prod.google.com [10.243.50.141]) by wpaz9.hot.corp.google.com with ESMTP id p2AJnTwf023610 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 10 Mar 2011 11:49:49 -0800 Received: by gyg13 with SMTP id 13so1078028gyg.20 for ; Thu, 10 Mar 2011 11:49:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sE0Fg7fEZ3Sf217Q8umj+PiqTbh67GIqKRabp7p+qws=; b=XqCsFBdv8N4VOW3owkpz9cUnaikUSxJkzscTDU0RTMIgAL9rzouqIOMWEJsP7bSFOS 5Tjj9gZB9dbGbzD8i2FA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=tErwJ/YT05sqazXjwwlU8wcvOWTspLVaIi77oCi/meda5jUw83i3uVF6JJGTbuPdKp NR7S6ZJlB5NrOZ7ipzDg== Received: by 10.150.170.19 with SMTP id s19mr1516340ybe.67.1299786589129; Thu, 10 Mar 2011 11:49:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Thu, 10 Mar 2011 11:49:29 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> From: John Tamplin Date: Thu, 10 Mar 2011 14:49:29 -0500 Message-ID: To: David Endicott Content-Type: multipart/alternative; boundary=000e0cd4cc3cedce77049e26259b X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 19:48:35 -0000 --000e0cd4cc3cedce77049e26259b Content-Type: text/plain; charset=UTF-8 On Thu, Mar 10, 2011 at 2:36 PM, David Endicott wrote: > Afterthought: an unmasked header would allow Websocket aware > intermediaries to manipulate frames without unmasking them. > Websocket aware load balancers and distributed frameworks come to > mind. Right, that has been the main objection (by my estimation anyway) to masking the header. However, unmasking 2-10 bytes doesn't seem like a large burden. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd4cc3cedce77049e26259b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 10, 2011 at 2:36 PM, David Endicott = <dendicott@gmai= l.com> wrote:
Afterthought: =C2=A0an unmasked header would allow Websocket aware
intermediaries to manipulate frames without unmasking them.
Websocket aware load balancers and distributed frameworks come to
mind.

Right, that has been the main objecti= on (by my estimation anyway) to masking the header. =C2=A0However, unmaskin= g 2-10 bytes doesn't seem like a large burden.=C2=A0

-- =
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd4cc3cedce77049e26259b-- From dendicott@gmail.com Thu Mar 10 11:58:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534B13A692B for ; Thu, 10 Mar 2011 11:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK+d2qIMFelU for ; Thu, 10 Mar 2011 11:58:41 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 5A1B03A67FF for ; Thu, 10 Mar 2011 11:58:41 -0800 (PST) Received: by wwa36 with SMTP id 36so1674684wwa.13 for ; Thu, 10 Mar 2011 11:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ujtm/Z1qa+MLzjlhB4VJXIzgrfIORemlQq0D79SSB5U=; b=NNIJcXCCkXv6fP3AbUSPZ0fHtVJBo7/OjN6HTw3m2O/fCTJg6nAAmS+1oDfXPZ5Skd jwUB4Ibtv4238tXnkYtCYGfaaPdhBaCJhUI/5GBqjAGVav33i4RAzaFJtkcvir/Yl3Ml CIZKijIiawTLY3jhZ/5hafPUSHnUuL4fiL7E8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IrdJcCulcFSETFArxe9sglXwQaR25ySyId1ch6Defyx2sx4IdEtJc5t0TPB7Nc8onn Sp09ZxDBt5Ws4smpOJ1pmNOwxeaxylnGQRC7FAJ22+/hyZu38okZq2JT3VuhDWHtplYv S4pcYTd3ySSSSKiiYi0G6+xwCH4wWk1r+87Vk= MIME-Version: 1.0 Received: by 10.216.171.133 with SMTP id r5mr6030647wel.91.1299787198279; Thu, 10 Mar 2011 11:59:58 -0800 (PST) Received: by 10.216.122.13 with HTTP; Thu, 10 Mar 2011 11:59:58 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> Date: Thu, 10 Mar 2011 14:59:58 -0500 Message-ID: From: David Endicott To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 19:58:42 -0000 Certainly not for a computer. (But I'm getting older and it's becoming difficult to xor in my head these days.) But any extra work is extra work, and if the agent is manipulating frames without processing them then its likely performance is a concern. Not that I really think xor'ing a few bytes is going to cost enough clock cycles to matter. My vote is thus: ambivalent; with a logically weak prejudice for unmasked headers. On Thu, Mar 10, 2011 at 2:49 PM, John Tamplin wrote: > On Thu, Mar 10, 2011 at 2:36 PM, David Endicott wro= te: >> >> Afterthought: =A0an unmasked header would allow Websocket aware >> intermediaries to manipulate frames without unmasking them. >> Websocket aware load balancers and distributed frameworks come to >> mind. > > Right, that has been the main objection (by my estimation anyway) to mask= ing > the header. =A0However, unmasking 2-10 bytes doesn't seem like a large > burden. > -- > John A. Tamplin > Software Engineer (GWT), Google > From theturtle32@gmail.com Thu Mar 10 12:55:37 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A843A699C for ; Thu, 10 Mar 2011 12:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhY2R1AZdnCz for ; Thu, 10 Mar 2011 12:55:36 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 282D13A67F8 for ; Thu, 10 Mar 2011 12:55:36 -0800 (PST) Received: by gwb20 with SMTP id 20so789604gwb.31 for ; Thu, 10 Mar 2011 12:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uAjcYTrCMbQix4Q3+NoSN7aLGqXhaHlmMq7cTxp1wBM=; b=PG7EJephiUVVrVNC0RAlx1pMhWoMmsz5GftQIL8p+Iw5mfhSu5AQL9iN/v9vUoDtLl Lk/1vM5jvYRKGvkro0pNcgyL1pl+3607rNmSAImVM1JgVfdxlrbgQJchEkLQ6i1005Di R619RLtIKCwxlpaN0n8QcigUQSfmqDRHYyrZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lHN+J2UnA/iYMSzrb5A/sk6EMTkGL4XGfyDf2bTCT2B3ikIbLvXj0i8Ofxwv2qQhGA Ghr4sB8lM7oZ0OJM/liJsE5J0/iZTEH68YjOUaHvurGevafDVoFhIW3u2fhg0x5BClGq quWipJ+QSPxrDKkkwqLEJqXV/Evtv6vQ4Ifyc= MIME-Version: 1.0 Received: by 10.42.213.193 with SMTP id gx1mr3568353icb.509.1299790613414; Thu, 10 Mar 2011 12:56:53 -0800 (PST) Received: by 10.231.149.19 with HTTP; Thu, 10 Mar 2011 12:56:53 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> Date: Thu, 10 Mar 2011 12:56:53 -0800 Message-ID: From: Brian To: David Endicott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 20:55:37 -0000 Just a quick updated tally of support/opposition: By my count, we now have eight voices in favor so far, including myself: Andy Green Ytaka Takeda Greg Wilkins Willy Tarreau Joel Martin Brian McKelvey Bruce Atherton Julian Reschke Three on record as not having a strong opinion one way or the other: Ian Fette John Endicott (Generally in favor, but not strongly so) John Tamplin (Generally opposed, but hasn't mentioned a strong opposition that I've seen) And two opposed: Adam Barth Patrick McManus If I've missed or misrepresented anyone, please let me know. I agree with Bruce in that I feel that pretty much everything that can be said on the topic at hand has been said. Sal, what is the next step for the WG toward a declaration of consensus one way or the other? Do we need a hum or formal straw poll, or will this thread suffice as such? Is further discussion warranted? Brian On Thu, Mar 10, 2011 at 11:59 AM, David Endicott wrot= e: > Certainly not for a computer. =A0(But I'm getting older and it's > becoming difficult to xor in my head these days.) > > But any extra work is extra work, and if the agent is manipulating > frames without processing them then its likely performance is a > concern. =A0Not that I really think xor'ing a few bytes is going to cost > enough clock cycles to matter. > > My vote is thus: ambivalent; with a logically weak prejudice for > unmasked headers. > > > On Thu, Mar 10, 2011 at 2:49 PM, John Tamplin wrote: >> On Thu, Mar 10, 2011 at 2:36 PM, David Endicott wr= ote: >>> >>> Afterthought: =A0an unmasked header would allow Websocket aware >>> intermediaries to manipulate frames without unmasking them. >>> Websocket aware load balancers and distributed frameworks come to >>> mind. >> >> Right, that has been the main objection (by my estimation anyway) to mas= king >> the header. =A0However, unmasking 2-10 bytes doesn't seem like a large >> burden. >> -- >> John A. Tamplin >> Software Engineer (GWT), Google >> > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From gregw@intalio.com Thu Mar 10 13:21:05 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9E63A6A7F for ; Thu, 10 Mar 2011 13:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guPmm6M3YIy6 for ; Thu, 10 Mar 2011 13:21:04 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id E537C3A6AC4 for ; Thu, 10 Mar 2011 13:21:03 -0800 (PST) Received: by gwb20 with SMTP id 20so800709gwb.31 for ; Thu, 10 Mar 2011 13:22:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.65.225 with SMTP id a1mr3603452vdt.183.1299792141896; Thu, 10 Mar 2011 13:22:21 -0800 (PST) Received: by 10.52.169.39 with HTTP; Thu, 10 Mar 2011 13:22:21 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <20110310103914.GA32389@1wt.eu> <1299769498.2606.252.camel@ds9.ducksong.com> <4D78EFFD.5040906@warmcat.com> Date: Fri, 11 Mar 2011 08:22:21 +1100 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:21:05 -0000 On 11 March 2011 03:22, John Tamplin wrote: > While I agree it is awkward to not be able to have a totally separate layer > where the masking is removed (since you can't know the length of the masked > frames without looking inside the masking), I don't think anyone is going to > implement it that way. If masking is removed from the framing, Jetty will certainly be implementing masking as a separate layer. It would be applied internally as an extension. > I don't see a difference here either -- if in the future a more > sophisticated masking is required, an extension would be negotiated that > will change it. But that will not be possible because intermediaries and tools will have been written that must understand the masking, so they can understand the framing. We know that it is impossible to suddenly change all intermediaries or even to negotiate different protocols through them. Once you make masking part of the framing, it will be there forever. The only way to achieve flexibility with masking is to allow elements that don't care about masking (ie most intermediaries) to not have to implement masking. > for example, imagine the deflate-stream extension in -06 was not > part of the standard but a later extension. For the same reasons, I think deflate-stream is a bad idea. If it was a good idea, then somebody would have done it to HTTP a long time ago to reduce the verbosity of HTTP headers. cheers From gregw@intalio.com Thu Mar 10 13:25:37 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47E223A6A5D for ; Thu, 10 Mar 2011 13:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7mFkqEQZNai for ; Thu, 10 Mar 2011 13:25:36 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 362AC3A6A7D for ; Thu, 10 Mar 2011 13:25:36 -0800 (PST) Received: by vxg33 with SMTP id 33so2344862vxg.31 for ; Thu, 10 Mar 2011 13:26:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.180.166 with SMTP id dp6mr76267vdc.63.1299792414243; Thu, 10 Mar 2011 13:26:54 -0800 (PST) Received: by 10.52.169.39 with HTTP; Thu, 10 Mar 2011 13:26:54 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> Date: Fri, 11 Mar 2011 08:26:54 +1100 Message-ID: From: Greg Wilkins To: Brian Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:25:37 -0000 I would like to note a procedural issue that has occurred many times in this working group. Things like masked framing have been added to the specification without consensus (there was consensus on masking, but objections had been raised regarding the masking before it was added). We then have to argue to have the feature removed and if consensus is not achieve then that feature remains. This in effect means that the status quo is to add a non- consensus feature. Surely this should have been done the other way around. A broad consensus should have been achieved in the WG before such a significant change the the agreed framing was put into the draft. regards On 11 March 2011 07:56, Brian wrote: > Just a quick updated tally of support/opposition: > > By my count, we now have eight voices in favor so far, including myself: > Andy Green > Ytaka Takeda > Greg Wilkins > Willy Tarreau > Joel Martin > Brian McKelvey > Bruce Atherton > Julian Reschke > > Three on record as not having a strong opinion one way or the other: > Ian Fette > John Endicott (Generally in favor, but not strongly so) > John Tamplin (Generally opposed, but hasn't mentioned a strong > opposition that I've seen) > > > And two opposed: > Adam Barth > Patrick McManus > > If I've missed or misrepresented anyone, please let me know. > > I agree with Bruce in that I feel that pretty much everything that can > be said on the topic at hand has been said. =A0Sal, what is the next > step for the WG toward a declaration of consensus one way or the > other? =A0Do we need a hum or formal straw poll, or will this thread > suffice as such? =A0Is further discussion warranted? > > > Brian > > > On Thu, Mar 10, 2011 at 11:59 AM, David Endicott wr= ote: >> Certainly not for a computer. =A0(But I'm getting older and it's >> becoming difficult to xor in my head these days.) >> >> But any extra work is extra work, and if the agent is manipulating >> frames without processing them then its likely performance is a >> concern. =A0Not that I really think xor'ing a few bytes is going to cost >> enough clock cycles to matter. >> >> My vote is thus: ambivalent; with a logically weak prejudice for >> unmasked headers. >> >> >> On Thu, Mar 10, 2011 at 2:49 PM, John Tamplin wrote: >>> On Thu, Mar 10, 2011 at 2:36 PM, David Endicott w= rote: >>>> >>>> Afterthought: =A0an unmasked header would allow Websocket aware >>>> intermediaries to manipulate frames without unmasking them. >>>> Websocket aware load balancers and distributed frameworks come to >>>> mind. >>> >>> Right, that has been the main objection (by my estimation anyway) to ma= sking >>> the header. =A0However, unmasking 2-10 bytes doesn't seem like a large >>> burden. >>> -- >>> John A. Tamplin >>> Software Engineer (GWT), Google >>> >> _______________________________________________ >> 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 > From gregw@intalio.com Thu Mar 10 13:26:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C6C3A6A7D for ; Thu, 10 Mar 2011 13:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WM9KzjEx4n+Y for ; Thu, 10 Mar 2011 13:26:50 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4B2353A6A5D for ; Thu, 10 Mar 2011 13:26:50 -0800 (PST) Received: by vws12 with SMTP id 12so704vws.31 for ; Thu, 10 Mar 2011 13:28:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.69.46 with SMTP id b14mr6909480vdu.103.1299792488379; Thu, 10 Mar 2011 13:28:08 -0800 (PST) Received: by 10.52.169.39 with HTTP; Thu, 10 Mar 2011 13:28:08 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> Date: Fri, 11 Mar 2011 08:28:08 +1100 Message-ID: From: Greg Wilkins To: Brian Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:26:51 -0000 On 11 March 2011 08:26, Greg Wilkins wrote: > Things like masked framing have been added to the specification > without consensus (there was consensus on masking, but objections had > been raised regarding the masking before it was added). oops - I mean to say: there was consensus on masking, but objections had been raised regarding masking the framing before it was added. cheers From jat@google.com Thu Mar 10 13:32:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39DF3A6B56 for ; Thu, 10 Mar 2011 13:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.84 X-Spam-Level: X-Spam-Status: No, score=-105.84 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9XmH3sif4Rt for ; Thu, 10 Mar 2011 13:32:57 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 9F7913A6ADE for ; Thu, 10 Mar 2011 13:32:54 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p2ALYB3t028970 for ; Thu, 10 Mar 2011 13:34:11 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299792852; bh=37uAMkT1ZFflqGLAkn4xA5VjbOs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=RVCakt71mlZEdJlKuWPJPKmgXzfzM2j6ZXjx1A+8ytrDfn727R1a/OUwDuoXK05tw YjTud17fnmM/Cf5YeHVPQ== Received: from yib2 (yib2.prod.google.com [10.243.65.66]) by wpaz17.hot.corp.google.com with ESMTP id p2ALXacZ010576 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 10 Mar 2011 13:34:10 -0800 Received: by yib2 with SMTP id 2so1026700yib.24 for ; Thu, 10 Mar 2011 13:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rzwRXkPB+0lEL0RxKQItwpmfGMGzD+m9fhqg7tOOnyo=; b=KDz8xXUvANXlsBDyOiydCEEXCMHbnqnR8J2yRWS6fyxuBD4P5aZ4wOWEAtETpn8uWO YcIZIr8AUhy8Z8wdaXLg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=h6D7Nl7u5krHZAHFtMSXdwJhrzdGe+aOPUAg9WUI0Q1oq7vhveVQeudwupVUElq97K U2lY4DxhvCjrkt9I9kwg== Received: by 10.150.99.19 with SMTP id w19mr1624914ybb.295.1299792850163; Thu, 10 Mar 2011 13:34:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Thu, 10 Mar 2011 13:33:50 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> From: John Tamplin Date: Thu, 10 Mar 2011 16:33:50 -0500 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd299a81d99c6049e279b56 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:32:58 -0000 --000e0cd299a81d99c6049e279b56 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 10, 2011 at 4:28 PM, Greg Wilkins wrote: > On 11 March 2011 08:26, Greg Wilkins wrote: > > Things like masked framing have been added to the specification > > without consensus (there was consensus on masking, but objections had > > been raised regarding the masking before it was added). > > oops - I mean to say: > > there was consensus on masking, but objections had been raised > regarding masking the framing before it was added. > I don't think there was consensus either way, but if a new draft was going to be written it had to say something and be something implementable -- it couldn't just say "WebSockets will implement masking, but we won't describe the details yet" as no implementations would be interoperable. I don't think the fact that the way it is in the draft requires a higher bar to change it than if it weren't in the draft. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd299a81d99c6049e279b56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 10, 2011 at 4:28 PM, Greg Wilkins <gregw@intalio.com<= /a>> wrote:
On 11 March 2011 08:26, Greg Wilkins <gregw@intalio.com> wrote:
> Things like masked framing have been added to the specification
> without consensus (there was consensus on masking, but objections had<= br> > been raised regarding the masking before it was added).

oops - I mean to say:

there was consensus on masking, but objections had been raised
regarding masking the framing before it was added.

I don't think there was consensus either way, but if = a new draft was going to be written it had to say something and be somethin= g implementable -- it couldn't just say "WebSockets will implement= masking, but we won't describe the details yet" as no implementat= ions would be interoperable.

I don't think the fact that the way it is in the dr= aft requires a higher bar to change it than if it weren't in the draft.= =C2=A0

--
John A. Tamplin
Software Engineer (GWT), Go= ogle
--000e0cd299a81d99c6049e279b56-- From gregw@intalio.com Thu Mar 10 13:55:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF293A6ABA for ; Thu, 10 Mar 2011 13:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sePKlz-0DVI1 for ; Thu, 10 Mar 2011 13:55:35 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id A12163A6AB1 for ; Thu, 10 Mar 2011 13:55:35 -0800 (PST) Received: by vxg33 with SMTP id 33so2383694vxg.31 for ; Thu, 10 Mar 2011 13:56:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.180.166 with SMTP id dp6mr119144vdc.63.1299794213712; Thu, 10 Mar 2011 13:56:53 -0800 (PST) Received: by 10.52.169.39 with HTTP; Thu, 10 Mar 2011 13:56:53 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> Date: Fri, 11 Mar 2011 08:56:53 +1100 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:55:36 -0000 On 11 March 2011 08:33, John Tamplin wrote: > On Thu, Mar 10, 2011 at 4:28 PM, Greg Wilkins wrote: >> >> On 11 March 2011 08:26, Greg Wilkins wrote: >> > Things like masked framing have been added to the specification >> > without consensus (there was consensus on masking, but objections had >> > been raised regarding the masking before it was added). >> >> oops - I mean to say: >> >> there was consensus on masking, but objections had been raised >> regarding masking the framing before it was added. > > I don't think there was consensus either way, but if a new draft was going > to be written it had to say something and be something implementable -- it > couldn't just say "WebSockets will implement masking, but we won't describe > the details yet" as no implementations would be interoperable. Indeed it couldn't and it had to say something concrete. But I think we needed to spend a bit more time discussion alternatives that would meet the consensus before we put such a significant change into the framing. But I think there was some alternative fatigue at that point, so it is somewhat understandable... just unfortunate (and a repeated anti-pattern). > I don't think the fact that the way it is in the draft requires a higher bar > to change it than if it weren't in the draft. Unfortunately the bar is higher. If we don't reach consensus to remove masking from the framing now, then framing would have been significantly changed without any consensus. I think the chairs need to consider that when making the call on this issue - as it is not unanimous. cheers From jat@google.com Thu Mar 10 13:58:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EEC23A6ADE for ; Thu, 10 Mar 2011 13:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.937 X-Spam-Level: X-Spam-Status: No, score=-105.937 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkdgL5sjTIPe for ; Thu, 10 Mar 2011 13:58:47 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 477563A6A79 for ; Thu, 10 Mar 2011 13:58:47 -0800 (PST) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p2AM05Iw010078 for ; Thu, 10 Mar 2011 14:00:05 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299794405; bh=oD4xUTg0mkjdvXSCofWhKxcGHiw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=h3K0EaXHhmn/UPdd9VkHlXlz7w7NGE2cXdI77K74k2inAoTtQSvfQgtr54sq42ymm nByxAYEswXK0ZDVtOYb2Q== Received: from gwb11 (gwb11.prod.google.com [10.200.2.11]) by kpbe17.cbf.corp.google.com with ESMTP id p2AM03ZN020131 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 10 Mar 2011 14:00:04 -0800 Received: by gwb11 with SMTP id 11so677845gwb.6 for ; Thu, 10 Mar 2011 14:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OpX9pnFYZYHMlXWH++ya821X6le7RXlbjGRiD7VEndE=; b=CRk6W3lPjc8l0WkN009VGm5Ueyy4syKsvlByIZl2rk+aXGxwinpacetN5aspQ5vdgR 6Seh13wPpnJwv1fq1KYQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=nLWjCQV2aDv066yrN9HETXjyl9S0wC+tByTIwuXS4t4guOMjsusg1Q7pXiIM+In4Oh NK8rXqNwOLvn22ZabtHQ== Received: by 10.150.99.19 with SMTP id w19mr1656577ybb.295.1299794403144; Thu, 10 Mar 2011 14:00:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Thu, 10 Mar 2011 13:59:43 -0800 (PST) In-Reply-To: References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> From: John Tamplin Date: Thu, 10 Mar 2011 16:59:43 -0500 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd299a8ae365e049e27f79b X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:58:48 -0000 --000e0cd299a8ae365e049e27f79b Content-Type: text/plain; charset=UTF-8 On Thu, Mar 10, 2011 at 4:56 PM, Greg Wilkins wrote: > > I don't think the fact that the way it is in the draft requires a higher > bar > > to change it than if it weren't in the draft. > > Unfortunately the bar is higher. If we don't reach consensus to > remove masking from the framing now, then framing would have been > significantly changed without any consensus. I think the chairs > need to consider that when making the call on this issue - as it is > not unanimous. > If we don't reach consensus on how masking should be done, then we don't have a final spec yet. It doesn't matter which alternative that lacks sufficient support is mentioned in the draft, it still isn't done at that point. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd299a8ae365e049e27f79b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 10, 2011 at 4:56 PM, Greg Wilkins <gregw@intalio.com<= /a>> wrote:
> I don't think the fact that the way it is in the= draft requires a higher bar
> to change it than if it weren't in the draft.

Unfortunately the bar is higher. =C2=A0If we don't reach consensu= s to
remove masking from the framing now, then framing would have been
significantly changed without any consensus. =C2=A0 =C2=A0 I think the chai= rs
need to consider that when making the call on this issue - as it is
not unanimous.

If we don't reach co= nsensus on how masking should be done, then we don't have a final spec = yet. =C2=A0It doesn't matter which alternative that lacks sufficient su= pport is mentioned in the draft, it still isn't done at that point.=C2= =A0

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd299a8ae365e049e27f79b-- From tyoshino@google.com Thu Mar 10 16:53:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A4A3A6AA8 for ; Thu, 10 Mar 2011 16:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.776 X-Spam-Level: X-Spam-Status: No, score=-105.776 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSBtQG4sgHk7 for ; Thu, 10 Mar 2011 16:53:50 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 0247D3A6A03 for ; Thu, 10 Mar 2011 16:53:48 -0800 (PST) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p2B0t6Ah022726 for ; Thu, 10 Mar 2011 16:55:06 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299804906; bh=McI4CD+Zrk9fbnpLThy6uCSmI1M=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ou3CzJ1R21ZQl0svXgd76Dbw0o7e4NmPhySiL8CLkcWqmghp+ENtXo22ZHvLPjcdV EBYIP4KSjRx8LREQiFHHg== Received: from iwn33 (iwn33.prod.google.com [10.241.68.97]) by kpbe15.cbf.corp.google.com with ESMTP id p2B0slvk029734 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 10 Mar 2011 16:55:05 -0800 Received: by iwn33 with SMTP id 33so3457203iwn.27 for ; Thu, 10 Mar 2011 16:55:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9nsii4R3e92tVFia9nv+KXLHq95RRQRsnxv7pLx1xeE=; b=kFlT+FUL8BZKxurHOESmURhxVvELJPczEo4W5mupqArIRQNWBdO2rE0zphHCHVGs75 Fyg/gmKaIifVHdrLuxGQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=qnkPOLrcdAjnmL57/R8AiHFPvy7kiIgp0aV0mpANjYOg7q6V3jSsLaX6ZTWwwuwBXg HS50HV26o+vUYa967N3w== Received: by 10.231.165.207 with SMTP id j15mr6703860iby.40.1299804905171; Thu, 10 Mar 2011 16:55:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.14.141 with HTTP; Thu, 10 Mar 2011 16:54:45 -0800 (PST) In-Reply-To: References: <4D77FB84.9010104@warmcat.com> <4D789223.8010208@warmcat.com> <4D78C12C.1080108@warmcat.com> From: Takeshi Yoshino Date: Fri, 11 Mar 2011 09:54:45 +0900 Message-ID: To: John Tamplin Content-Type: multipart/alternative; boundary=000325572a1ea66acb049e2a695c X-System-Of-Record: true Cc: hybi@ietf.org, Yutaka_Takeda@playstation.sony.com Subject: Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 00:53:51 -0000 --000325572a1ea66acb049e2a695c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 11, 2011 at 01:31, John Tamplin wrote: > On Thu, Mar 10, 2011 at 7:34 AM, Takeshi Yoshino wrote: > >> OK. So we can add an implementation note like this. >> >> Senders using this extension MUST apply RFC 1951 DEFLATE to all the bytes >>> of the application data portion of data frames. Senders MAY include multiple >>> blocks in a frame. Senders MAY use blocks of any type as defined in RFC >>> 1951. Senders MUST use the algorithm described in Section 2.1 of RFC1979 to >>> align compressed data to byte boundary. Senders MAY keep using the same LZ77 >>> sliding window for multiple frames. >> >> >> If you're using zlib for applying DEFLATE compression, specify >> Z_SYNC_FLUSH when you flush the last octets of application data for each >> frame (in case the last block is non-compressed block (BTYPE=00), append one >> empty compressed block (BTYPE=01)), and then strip the last 4 octets from >> the compressed octets. >> >> Receivers MUST append 0x00 0x00 0xff 0xff to the application data portion >>> and decompress it using DEFLATE to decode the original application data. >>> Receivers MUST keep using the same LZ77 sliding window for all the frames of >>> the same WebSocket connection. Receivers MUST assume the senders use 32768 >>> byte LZ77 sliding window. >> >> >> If you're using zlib for applying DEFLATE compression, for each received >> frame, concatenate 4 octets 0x00 0x00 0xff 0xff and the application data, >> and then supply the resulting bytes to zlib and use the uncompressed data. >> > > zlib is just one implementation, and I don't think the spec should be > choosing one implementation instead of the algorithm. Therefore, we > shouldn't be using zlib-specific terminology in the spec. > So, the note including zlib terms should go somewhere else than the spec text. IMO at least we should explain what implementors actually should do to align to octet boundary, and place that somewhere they can easily get to. The current deflate-stream spec just says "Senders MUST NOT delay the transmission of any portion of a WebSocket message because the deflate encoding of the message does not end on a byte boundary". It's not so easy for implementors to know what to do and be convinced what they're doing is correct. The octet aligning method is NOT explained in RFC1951. If we could add some text like "For example, you can do this by adding BTYPE=00 block" (and at least add reference to zlib since it's not our invention), implementors can understand what to do just by reading WebSocket spec and RFC1951. No need to use Z_ stuff. > > I don't object to compressing only the payload (though it does make > implementations more complicated, rather than just pushing a > compressor/decompressor onto the stream having to switch back and forth), > but couldn't the issue we are trying to solve here be done by just saying > that if deflate-stream is negotiated and a close frame is read, you cannot > initiate close processing until the final compressed block is read > completely? > That's the quick fix to the deflate-stream extension I proposed above. I want a short note in the spec saying that the sender should finalize the stream after the close frame by BFINAL=1 block". Some may immediately understand the deflate stream should finalized after the close by just reading "Senders using this extension MUST apply RFC 1951 encodings to all bytes of the data stream following the handshake including both data and control messages.", but expecting implementors to guess is not good, I think. > > In any case, I think deflate-stream is only a stop-gap solution to get some > form of compression in the spec, also serving as an example extension. I > think realistically we are going to have to have the ability to avoid > compressing incompressible data in the stream. > I agree this point. I'm not objecting to having deflate-stream in the initial spec. > Initially, where WebSockets implementations only support plain text, this > won't be much of a problem, but eventually clients will be mixing binary > data with their text and we would prefer to be able to use compression where > it helps and not use it where it hurts. > > -- > John A. Tamplin > Software Engineer (GWT), Google > --000325572a1ea66acb049e2a695c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 11, 2011 at 01:31, John Tamplin <jat@google.com><= /span> wrote:
On Thu, Mar 10, 2011 at 7:34 A= M, Takeshi Yoshino <tyoshino@google.com> wrote:
OK. So we can add an implem= entation note like this.

Senders using this extension MUST apply RFC 1951 DEFLATE to all the bytes o= f the application data portion of data frames. Senders MAY include multiple= blocks in a frame. Senders MAY use blocks of any type as defined in RFC 19= 51. Senders MUST use the algorithm described in Section 2.1 of RFC1979 to a= lign compressed data to byte boundary. Senders MAY keep using the same LZ77= sliding window for multiple frames.

If you're using zlib for applying DEFLATE compressi= on, specify Z_SYNC_FLUSH when you flush the last octets of application data= for each frame (in case the last block is non-compressed block (BTYPE=3D00= ), append one empty compressed block (BTYPE=3D01)), and then strip the last= 4 octets from the compressed octets.


I don't object to compressing only the payloa= d (though it does make implementations more complicated, rather than just p= ushing a compressor/decompressor onto the stream having to switch back and = forth), but couldn't the issue we are trying to solve here be done by j= ust saying that if deflate-stream is negotiated and a close frame is read, = you cannot initiate close processing until the final compressed block is re= ad completely?
That's the quick fix to the deflate-stream extension = I proposed above.=A0I want a short note in the spec saying that the sender = should finalize the stream after the close frame by BFINAL=3D1 block".=

Some may immediately understand the deflate stream shou= ld finalized after the close by just reading "Senders using this exten= sion MUST apply RFC 1951 encodings to all bytes of the data stream followin= g the handshake including both data=A0and control messages.", but expe= cting implementors to guess is not good, I think.
=A0

In any case, I think deflate-stream is only a stop-gap = solution to get some form of compression in the spec, also serving as an ex= ample extension. =A0I think realistically we are going to have to have the = ability to avoid compressing incompressible data in the stream.

I agree this point. I'm not objecting = to having deflate-stream in the initial spec.
=A0
=A0Initially, where WebSockets implementations only support plain tex= t, this won't be much of a problem, but eventually clients will be mixi= ng binary data with their text and we would prefer to be able to use compre= ssion where it helps and not use it where it hurts.

--
John A. Tamplin
Software Engineer (GWT), Google

--000325572a1ea66acb049e2a695c-- From salvatore.loreto@ericsson.com Fri Mar 11 04:57:29 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9C73A6BBF for ; Fri, 11 Mar 2011 04:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1Xtk-RzgYII for ; Fri, 11 Mar 2011 04:57:28 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C51C93A6985 for ; Fri, 11 Mar 2011 04:57:27 -0800 (PST) X-AuditID: c1b4fb3d-b7bbbae000005311-c8-4d7a1c852309 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E0.E1.21265.58C1A7D4; Fri, 11 Mar 2011 13:58:46 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Fri, 11 Mar 2011 13:58:45 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 766E926FD for ; Fri, 11 Mar 2011 14:58:45 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 35B665022B for ; Fri, 11 Mar 2011 14:58:45 +0200 (EET) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DAD174F66F for ; Fri, 11 Mar 2011 14:58:44 +0200 (EET) Message-ID: <4D7A1C84.3080101@ericsson.com> Date: Fri, 11 Mar 2011 14:58:44 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: hybi@ietf.org References: <4D77B885.5050109@callenish.com> <1299704939.2606.238.camel@ds9.ducksong.com> <20110309214212.GA29190@1wt.eu> <4D7915FF.50300@callenish.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] Masking only Payload/Extension Data X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 12:57:29 -0000 On 3/10/11 10:56 PM, Brian wrote: > Sal, what is the next > step for the WG toward a declaration of consensus one way or the > other? Do we need a hum or formal straw poll, or will this thread > suffice as such? Is further discussion warranted? Hi there, I think this is a meaningful thread, that absolutely needs further discussions before a declaration of consensus one way or the other! we have Monday March 14th as deadline for draft to be considered at IETF80 meeting in Prague ( http://www.ietf.org/meeting/80/index.html ). Ian Fette (who btw is in Japan) is working on a 07 version of the draft, not sure (due to the situation in Japan) if he will be able to meet the deadline; in the case he will, 07 won't include any changes related to the masking issue. To be clear and avoid misunderstanding: 07 will be just one more step but not the final candidate version... things can (will) still change on the issues we know do not have reached consensus (e.g. whether to mask the framing or not), but changes can also come from possible feedback from implementation and operational experience. as next steps I would suggest: -it would be worth to discuss the issue during our 2hours f2f meeting in Prague. if any of the people in favor (or opposing) of 'Masking only Payload' is planning to attend the meeting, I will be happy to give him a slot to present/discuss the issue. (please contact me if you want the slot) Note1: there is the possibility to attend the meeting remotely (via audio streaming and jabber; or we can setup some collaboration tool for it), but to have a good discussion we need at least one champion being physically present in the meeting Note2: remember http://tools.ietf.org/html/rfc4677#section-5.2 -keep discussing in the mailing list and if we won't reach a consensus Joe and I will decide what to do (e.g. if we need an hum/straw poll etc.) cheers /Sal -- Salvatore Loreto www.sloreto.com From Gabriel.Montenegro@microsoft.com Sat Mar 12 18:46:27 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879333A6A85 for ; Sat, 12 Mar 2011 18:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.514 X-Spam-Level: X-Spam-Status: No, score=-10.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdCMEePWaHHS for ; Sat, 12 Mar 2011 18:46:26 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 6EBC53A6A82 for ; Sat, 12 Mar 2011 18:46:26 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 12 Mar 2011 18:47:47 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.270.2; Sat, 12 Mar 2011 18:47:47 -0800 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.139]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Sat, 12 Mar 2011 18:47:47 -0800 From: Gabriel Montenegro To: "hybi@ietf.org" Thread-Topic: fyi: Microsoft HTML5 Labs prototype updated to version 06 Thread-Index: AcvhKP7t2Pitti/+TKyhhAdxZRZxhA== Date: Sun, 13 Mar 2011 02:47:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C1126ED7407TK5EX14MBXW602w_" MIME-Version: 1.0 Subject: [hybi] fyi: Microsoft HTML5 Labs prototype updated to version 06 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 02:46:27 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1126ED7407TK5EX14MBXW602w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In addition to libwebsockets, the prototyped interoperates with Jetty and w= ith the websockets Firefox build. Blog entry with further details: http://blogs.msdn.com/b/interoperability/archive/2011/03/09/latest-websocke= ts-release-interoperates-with-eclipse-s-jetty.aspx Prototype available here: http://html5labs.interoperabilitybridges.com/prototypes/available-for-downl= oad/websockets --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1126ED7407TK5EX14MBXW602w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In addition to libwebsockets, the prototyped interop= erates with Jetty and with the websockets Firefox build.

 

Blog entry with further details:

http://blogs.msdn.com/b/interoperability/archive/2011/03/09/late= st-websockets-release-interoperates-with-eclipse-s-jetty.aspx

 

Prototype available here:

http://= html5labs.interoperabilitybridges.com/prototypes/available-for-download/web= sockets

 

 

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C1126ED7407TK5EX14MBXW602w_-- From gregw@intalio.com Mon Mar 14 06:39:35 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53203A6D18 for ; Mon, 14 Mar 2011 06:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RHLN190zjXp for ; Mon, 14 Mar 2011 06:39:34 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 2CF823A6958 for ; Mon, 14 Mar 2011 06:39:31 -0700 (PDT) Received: by vws12 with SMTP id 12so2969144vws.31 for ; Mon, 14 Mar 2011 06:40:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.175.104 with SMTP id bz8mr7670768vdc.143.1300110054020; Mon, 14 Mar 2011 06:40:54 -0700 (PDT) Received: by 10.52.169.39 with HTTP; Mon, 14 Mar 2011 06:40:53 -0700 (PDT) In-Reply-To: References: <1299520117.2606.130.camel@ds9.ducksong.com> <4D7552FD.9090002@warmcat.com> Date: Tue, 15 Mar 2011 00:40:53 +1100 Message-ID: From: Greg Wilkins To: hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] interop tests - fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 13:39:35 -0000 Since not everybody doing interop will be familiar with Java, I thought I'd post some more explicit instructions of how to run the jetty test client/server, plus descriptions of the test protocols that they are using. You can get the latest jetty aggregate jar with: wget -O jetty-all.jar https://oss.sonatype.org/content/groups/jetty-with-staging/org/eclipse/jetty/aggregate/jetty-all/7.3.2-SNAPSHOT/jetty-all-7.3.2-20110314.133648-9.jar you also need a servlet jar: wget --user-agent=something http://repo2.maven.org/maven2/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar The server can then be run with java -cp jetty-all.jar:servlet-api-2.5.jar org.eclipse.jetty.websocket.TestServer --port 8080 And the client with: java -cp jetty-all.jar:servlet-api-2.5.jar org.eclipse.jetty.websocket.TestClient --help ERROR: [--help] USAGE: java -cp CLASSPATH class org.eclipse.jetty.websocket.TestClient [ OPTIONS ] -h|--host HOST (default localhost) -p|--port PORT (default 8080) -b|--binary -v|--verbose -c|--count n (default 10) -s|--size n (default 64) -f|--fragment n (default 4000) -P|--protocol echo|echo-assemble|echo-fragment|echo-broadcast The protocols supported are the ones I proposed earlier: org.ietf.websocket.test-echo Websocket messages are sent by the client and the server will echo every frame. org.ietf.websocket.test-echo-broadcast Websocket messages are sent by the client and the server will echo every frame to every connection. org.ietf.websocket.test-echo-assemble Websocket messages are sent by the client and the server will echo assembled messages as a single frame. org.ietf.websocket.test-echo-fragment Websocket messages are sent and the server will echo each message fragmented into 2 frames. If there is no interest in making these common, then I'll drom the org.ietf prefix An example of running the test client is [558] java -cp jetty-all.jar:servlet-api-2.5.jar org.eclipse.jetty.websocket.TestClient --port 8080 --binary --count 3 --size 120 --fragment 40 --protocol echo-fragment Jetty WebSocket PING localhost:8080 (localhost/127.0.0.1:8080) 120 bytes of data. handshake OK for protocol 'org.ietf.websocket.test-echo-fragment' 120 bytes from localhost: frames=2 req=1 time=52.0ms opcode=0x05 120 bytes from localhost: frames=2 req=2 time=38.2ms opcode=0x05 120 bytes from localhost: frames=2 req=3 time=37.4ms opcode=0x05 --- localhost websocket ping statistics using 1 connection --- 9 frames transmitted, 6 received, 3 messages transmitted, 3 received, time 3009ms rtt min/ave/max = 37.448/42.534/51.974 ms So 3x120B binary messages were sent in 3x40B fragments, for a total of 9 frames sent. The echo-fragment protocol received these 3 messages and echoed each back in 2 fragments, for 6 frames received. cheers From Internet-Drafts@ietf.org Mon Mar 14 10:45:03 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367763A6DAB; Mon, 14 Mar 2011 10:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryNrnDsNtDgg; Mon, 14 Mar 2011 10:45:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9458F3A6D6C; Mon, 14 Mar 2011 10:45:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314174501.19846.11905.idtracker@localhost> Date: Mon, 14 Mar 2011 10:45:01 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action:draft-ietf-hybi-websocket-requirements-02.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 17:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BiDirectional or Server-Initiated HTTP Working Group of the IETF. Title : HyBi WebSocket Requirements and Features Author(s) : G. Montenegro Filename : draft-ietf-hybi-websocket-requirements-02.txt Pages : 9 Date : 2011-03-14 This document states the requirements of the WebSocket Protocol. The goal of the document is to provide a stable base for protocol design and related discussion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hybi-websocket-requirements-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-hybi-websocket-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14104322.I-D@ietf.org> --NextPart-- From gregw@intalio.com Tue Mar 15 16:19:00 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954F53A6EFE for ; Tue, 15 Mar 2011 16:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpfcgcsOlMzF for ; Tue, 15 Mar 2011 16:18:59 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 37D053A6944 for ; Tue, 15 Mar 2011 16:18:58 -0700 (PDT) Received: by vws12 with SMTP id 12so1291548vws.31 for ; Tue, 15 Mar 2011 16:20:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.90.10 with SMTP id bs10mr66315vdb.23.1300231224044; Tue, 15 Mar 2011 16:20:24 -0700 (PDT) Received: by 10.52.169.39 with HTTP; Tue, 15 Mar 2011 16:20:24 -0700 (PDT) In-Reply-To: References: <1299520117.2606.130.camel@ds9.ducksong.com> <4D7552FD.9090002@warmcat.com> Date: Wed, 16 Mar 2011 10:20:24 +1100 Message-ID: From: Greg Wilkins To: hybi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] interop tests - fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 23:19:00 -0000 hmmmm there is no chorus of approval for some common testing sub protocols - so unless anybody speaks up soon, I'll drop the org.ietf.websocket from the protocols that jetty implements. cheers On 15 March 2011 00:40, Greg Wilkins wrote: > Since not everybody doing interop will be familiar with Java, =A0I > thought I'd post some more explicit instructions of how to run the > jetty test client/server, plus descriptions of the test protocols that > they are using. > > You can get the latest jetty aggregate jar with: > =A0wget -O jetty-all.jar > https://oss.sonatype.org/content/groups/jetty-with-staging/org/eclipse/je= tty/aggregate/jetty-all/7.3.2-SNAPSHOT/jetty-all-7.3.2-20110314.133648-9.ja= r > > you also need a servlet jar: > =A0wget --user-agent=3Dsomething > http://repo2.maven.org/maven2/javax/servlet/servlet-api/2.5/servlet-api-2= .5.jar > > > The server can then be run with > > =A0java -cp jetty-all.jar:servlet-api-2.5.jar > org.eclipse.jetty.websocket.TestServer --port 8080 > > > And the client with: > > =A0java -cp jetty-all.jar:servlet-api-2.5.jar > org.eclipse.jetty.websocket.TestClient --help > =A0ERROR: [--help] > =A0USAGE: java -cp CLASSPATH class > org.eclipse.jetty.websocket.TestClient [ OPTIONS ] > =A0 =A0-h|--host HOST =A0(default localhost) > =A0 =A0-p|--port PORT =A0(default 8080) > =A0 =A0-b|--binary > =A0 =A0-v|--verbose > =A0 =A0-c|--count n =A0 =A0(default 10) > =A0 =A0-s|--size n =A0 =A0 (default 64) > =A0 =A0-f|--fragment n (default 4000) > =A0 =A0-P|--protocol echo|echo-assemble|echo-fragment|echo-broadcast > > > The protocols supported are the ones I proposed earlier: > > =A0 =A0org.ietf.websocket.test-echo > =A0 =A0 =A0 =A0Websocket messages are sent by the client and the server w= ill > echo every frame. > > =A0 =A0org.ietf.websocket.test-echo-broadcast > =A0 =A0 =A0 =A0Websocket messages are sent by the client and the server w= ill > echo every frame to every connection. > > =A0 =A0org.ietf.websocket.test-echo-assemble > =A0 =A0 =A0 =A0Websocket messages are sent by the client and the server w= ill > echo assembled messages as a single frame. > > =A0 =A0org.ietf.websocket.test-echo-fragment > =A0 =A0 =A0 =A0Websocket messages are sent and the server will echo each > message fragmented into 2 frames. > > > If there is no interest in making these common, then I'll drom the > org.ietf prefix > > An example of running the test client is > > [558] java -cp jetty-all.jar:servlet-api-2.5.jar > org.eclipse.jetty.websocket.TestClient --port 8080 --binary --count 3 > --size 120 --fragment 40 --protocol echo-fragment > Jetty WebSocket PING localhost:8080 (localhost/127.0.0.1:8080) 120 > bytes of data. > handshake OK for protocol 'org.ietf.websocket.test-echo-fragment' > 120 bytes from localhost: frames=3D2 req=3D1 time=3D52.0ms opcode=3D0x05 > 120 bytes from localhost: frames=3D2 req=3D2 time=3D38.2ms opcode=3D0x05 > 120 bytes from localhost: frames=3D2 req=3D3 time=3D37.4ms opcode=3D0x05 > --- localhost websocket ping statistics using 1 connection --- > 9 frames transmitted, 6 received, 3 messages transmitted, 3 received, > time 3009ms > rtt min/ave/max =3D 37.448/42.534/51.974 ms > > So 3x120B binary messages were sent in 3x40B fragments, for a total of > 9 frames sent. =A0The echo-fragment protocol received these 3 messages > and echoed each back in 2 fragments, for 6 frames received. > > > cheers > From Gabriel.Montenegro@microsoft.com Tue Mar 15 16:25:54 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D247E3A6EF2 for ; Tue, 15 Mar 2011 16:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.219 X-Spam-Level: X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiALuA0IfPa3 for ; Tue, 15 Mar 2011 16:25:53 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 1069B3A6DC6 for ; Tue, 15 Mar 2011 16:25:53 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 15 Mar 2011 16:27:18 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.270.2; Tue, 15 Mar 2011 16:27:18 -0700 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.139]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Tue, 15 Mar 2011 16:27:17 -0700 From: Gabriel Montenegro To: Greg Wilkins , hybi Thread-Topic: [hybi] interop tests - fragments Thread-Index: AQHL3O/1Ie40DDzS4kmHHL09NsuYWZQi72WAgAAGGICAAGDIgIAKABOAgAI0PwD//4w7IA== Date: Tue, 15 Mar 2011 23:27:17 +0000 Message-ID: References: <1299520117.2606.130.camel@ds9.ducksong.com> <4D7552FD.9090002@warmcat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] interop tests - fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 23:25:54 -0000 I think this is a good idea. W3C has test suites for the APIs, but there is= no equivalent for the protocol side at the IETF. This could be a way to in= corporate some standard tests. > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of G= reg > Wilkins > Sent: Tuesday, March 15, 2011 16:20 > To: hybi > Subject: Re: [hybi] interop tests - fragments >=20 > hmmmm there is no chorus of approval for some common testing sub protoco= ls > - so unless anybody speaks up soon, I'll drop the org.ietf.websocket from= the > protocols that jetty implements. >=20 > cheers >=20 >=20 > On 15 March 2011 00:40, Greg Wilkins wrote: > > Since not everybody doing interop will be familiar with Java, =A0I > > thought I'd post some more explicit instructions of how to run the > > jetty test client/server, plus descriptions of the test protocols that > > they are using. > > > > You can get the latest jetty aggregate jar with: > > =A0wget -O jetty-all.jar > > https://oss.sonatype.org/content/groups/jetty-with-staging/org/eclipse > > /jetty/aggregate/jetty-all/7.3.2-SNAPSHOT/jetty-all-7.3.2-20110314.133 > > 648-9.jar > > > > you also need a servlet jar: > > =A0wget --user-agent=3Dsomething > > http://repo2.maven.org/maven2/javax/servlet/servlet-api/2.5/servlet-ap > > i-2.5.jar > > > > > > The server can then be run with > > > > =A0java -cp jetty-all.jar:servlet-api-2.5.jar > > org.eclipse.jetty.websocket.TestServer --port 8080 > > > > > > And the client with: > > > > =A0java -cp jetty-all.jar:servlet-api-2.5.jar > > org.eclipse.jetty.websocket.TestClient --help > > =A0ERROR: [--help] > > =A0USAGE: java -cp CLASSPATH class > > org.eclipse.jetty.websocket.TestClient [ OPTIONS ] > > =A0 =A0-h|--host HOST =A0(default localhost) > > =A0 =A0-p|--port PORT =A0(default 8080) > > =A0 =A0-b|--binary > > =A0 =A0-v|--verbose > > =A0 =A0-c|--count n =A0 =A0(default 10) > > =A0 =A0-s|--size n =A0 =A0 (default 64) > > =A0 =A0-f|--fragment n (default 4000) > > =A0 =A0-P|--protocol echo|echo-assemble|echo-fragment|echo-broadcast > > > > > > The protocols supported are the ones I proposed earlier: > > > > =A0 =A0org.ietf.websocket.test-echo > > =A0 =A0 =A0 =A0Websocket messages are sent by the client and the server= will > > echo every frame. > > > > =A0 =A0org.ietf.websocket.test-echo-broadcast > > =A0 =A0 =A0 =A0Websocket messages are sent by the client and the server= will > > echo every frame to every connection. > > > > =A0 =A0org.ietf.websocket.test-echo-assemble > > =A0 =A0 =A0 =A0Websocket messages are sent by the client and the server= will > > echo assembled messages as a single frame. > > > > =A0 =A0org.ietf.websocket.test-echo-fragment > > =A0 =A0 =A0 =A0Websocket messages are sent and the server will echo eac= h > > message fragmented into 2 frames. > > > > > > If there is no interest in making these common, then I'll drom the > > org.ietf prefix > > > > An example of running the test client is > > > > [558] java -cp jetty-all.jar:servlet-api-2.5.jar > > org.eclipse.jetty.websocket.TestClient --port 8080 --binary --count 3 > > --size 120 --fragment 40 --protocol echo-fragment Jetty WebSocket PING > > localhost:8080 (localhost/127.0.0.1:8080) 120 bytes of data. > > handshake OK for protocol 'org.ietf.websocket.test-echo-fragment' > > 120 bytes from localhost: frames=3D2 req=3D1 time=3D52.0ms opcode=3D0x0= 5 > > 120 bytes from localhost: frames=3D2 req=3D2 time=3D38.2ms opcode=3D0x0= 5 > > 120 bytes from localhost: frames=3D2 req=3D3 time=3D37.4ms opcode=3D0x0= 5 > > --- localhost websocket ping statistics using 1 connection --- > > 9 frames transmitted, 6 received, 3 messages transmitted, 3 received, > > time 3009ms rtt min/ave/max =3D 37.448/42.534/51.974 ms > > > > So 3x120B binary messages were sent in 3x40B fragments, for a total of > > 9 frames sent. =A0The echo-fragment protocol received these 3 messages > > and echoed each back in 2 fragments, for 6 frames received. > > > > > > cheers > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From andy.warmcat.com@googlemail.com Tue Mar 15 23:40:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AB953A6805 for ; Tue, 15 Mar 2011 23:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.624 X-Spam-Level: X-Spam-Status: No, score=-3.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viQfLSGfMGXW for ; Tue, 15 Mar 2011 23:40:33 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 49C4C3A6804 for ; Tue, 15 Mar 2011 23:40:33 -0700 (PDT) Received: by wwk4 with SMTP id 4so3768826wwk.1 for ; Tue, 15 Mar 2011 23:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Lov2dIm5+lK74+HkfIWV/TM4Yl5TNtvgG3mbjUFLbJk=; b=Q5/tQWjHBEoREW6evnNokRXlV+J7xGldvVryx+knVY7fRFQOlO1Z7Du4bMD8GKQxgB ip4JkjH/0zT68qZm3enP6qFS5EKvBQpfCgyXlNPcIUiDe+5NespIh5FT6VL7GNaoumb8 A7Rgwt9Bx6dZNgB+9rbImT70kb3C8J9DBJIr8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=L8CZGUWGKTyzxRUC7/t0SM1DfN0jkFQLD9HdymIBi0NFvh9sh0YX4P5AdJci3MSS6C VCceB9ds3GvbusK9cPauwnNSq/rWAbsYG8+mF+EE6F395e9a3m6ZIZzhtZn58GqX9ZRS f07+XFpqG1rd5TMnynmnQH0f7FbLFK9ae3yrs= Received: by 10.227.172.193 with SMTP id m1mr368808wbz.201.1300257718426; Tue, 15 Mar 2011 23:41:58 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id x1sm755491wbh.2.2011.03.15.23.41.55 (version=SSLv3 cipher=OTHER); Tue, 15 Mar 2011 23:41:56 -0700 (PDT) Sender: Andy Green Message-ID: <4D805BB2.1050900@warmcat.com> Date: Wed, 16 Mar 2011 06:41:54 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8 MIME-Version: 1.0 To: Gabriel Montenegro References: <1299520117.2606.130.camel@ds9.ducksong.com> <4D7552FD.9090002@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi , Greg Wilkins Subject: Re: [hybi] interop tests - fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 06:40:34 -0000 On 03/15/2011 11:27 PM, Somebody in the thread at some point said: >> hmmmm there is no chorus of approval for some common testing sub >> protocols - so unless anybody speaks up soon, > I think this is a good idea. W3C has test suites for the APIs, but > there is no equivalent for the protocol side at the IETF. This could > be a way to incorporate some standard tests. Yeah I don't think it's a bad idea either. I will adapt the libwebsockets test server and fraggle when I get an evening free. -Andy From duerst@it.aoyama.ac.jp Wed Mar 16 02:03:46 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1A63A68BD for ; Wed, 16 Mar 2011 02:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.529 X-Spam-Level: X-Spam-Status: No, score=-99.529 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnILkrPhBbkM for ; Wed, 16 Mar 2011 02:03:45 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id A1A8D3A68B3 for ; Wed, 16 Mar 2011 02:03:44 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p2G9537f009233 for ; Wed, 16 Mar 2011 18:05:03 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 0955_0b45_79ed4a5c_4fac_11e0_8de3_001d096c566a; Wed, 16 Mar 2011 18:05:01 +0900 Received: from [IPv6:::1] ([133.2.210.1]:37769) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 16 Mar 2011 10:31:39 +0900 Message-ID: <4D8012D6.40605@it.aoyama.ac.jp> Date: Wed, 16 Mar 2011 10:31:02 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Gabriel Montenegro References: <1299520117.2606.130.camel@ds9.ducksong.com> <4D7552FD.9090002@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: hybi , Greg Wilkins Subject: Re: [hybi] interop tests - fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 09:03:47 -0000 I agree with Gabriel. I think common subprotocols and common frameworks and patterns is something that will draw attention in the websockets area soon. I think using the org.ietf.websocket label may be slightly premature, but as you have already used it, it's probably more confusing to change it, and then again change it back. I also think that writing an Internet Draft about the test protocols would be a good idea. This can be an individual draft and later be adopted by the WG (if we think we have the protocol itself sufficiently nailed down). Unfortunately, you have to wait two weeks for the submission to open again. Regards, Martin. On 2011/03/16 8:27, Gabriel Montenegro wrote: > I think this is a good idea. W3C has test suites for the APIs, but there is no equivalent for the protocol side at the IETF. This could be a way to incorporate some standard tests. > >> -----Original Message----- >> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Greg >> Wilkins >> Sent: Tuesday, March 15, 2011 16:20 >> To: hybi >> Subject: Re: [hybi] interop tests - fragments >> >> hmmmm there is no chorus of approval for some common testing sub protocols >> - so unless anybody speaks up soon, I'll drop the org.ietf.websocket from the >> protocols that jetty implements. >> >> cheers >> >> >> On 15 March 2011 00:40, Greg Wilkins wrote: >>> Since not everybody doing interop will be familiar with Java, I >>> thought I'd post some more explicit instructions of how to run the >>> jetty test client/server, plus descriptions of the test protocols that >>> they are using. >>> >>> You can get the latest jetty aggregate jar with: >>> wget -O jetty-all.jar >>> https://oss.sonatype.org/content/groups/jetty-with-staging/org/eclipse >>> /jetty/aggregate/jetty-all/7.3.2-SNAPSHOT/jetty-all-7.3.2-20110314.133 >>> 648-9.jar >>> >>> you also need a servlet jar: >>> wget --user-agent=something >>> http://repo2.maven.org/maven2/javax/servlet/servlet-api/2.5/servlet-ap >>> i-2.5.jar >>> >>> >>> The server can then be run with >>> >>> java -cp jetty-all.jar:servlet-api-2.5.jar >>> org.eclipse.jetty.websocket.TestServer --port 8080 >>> >>> >>> And the client with: >>> >>> java -cp jetty-all.jar:servlet-api-2.5.jar >>> org.eclipse.jetty.websocket.TestClient --help >>> ERROR: [--help] >>> USAGE: java -cp CLASSPATH class >>> org.eclipse.jetty.websocket.TestClient [ OPTIONS ] >>> -h|--host HOST (default localhost) >>> -p|--port PORT (default 8080) >>> -b|--binary >>> -v|--verbose >>> -c|--count n (default 10) >>> -s|--size n (default 64) >>> -f|--fragment n (default 4000) >>> -P|--protocol echo|echo-assemble|echo-fragment|echo-broadcast >>> >>> >>> The protocols supported are the ones I proposed earlier: >>> >>> org.ietf.websocket.test-echo >>> Websocket messages are sent by the client and the server will >>> echo every frame. >>> >>> org.ietf.websocket.test-echo-broadcast >>> Websocket messages are sent by the client and the server will >>> echo every frame to every connection. >>> >>> org.ietf.websocket.test-echo-assemble >>> Websocket messages are sent by the client and the server will >>> echo assembled messages as a single frame. >>> >>> org.ietf.websocket.test-echo-fragment >>> Websocket messages are sent and the server will echo each >>> message fragmented into 2 frames. >>> >>> >>> If there is no interest in making these common, then I'll drom the >>> org.ietf prefix >>> >>> An example of running the test client is >>> >>> [558] java -cp jetty-all.jar:servlet-api-2.5.jar >>> org.eclipse.jetty.websocket.TestClient --port 8080 --binary --count 3 >>> --size 120 --fragment 40 --protocol echo-fragment Jetty WebSocket PING >>> localhost:8080 (localhost/127.0.0.1:8080) 120 bytes of data. >>> handshake OK for protocol 'org.ietf.websocket.test-echo-fragment' >>> 120 bytes from localhost: frames=2 req=1 time=52.0ms opcode=0x05 >>> 120 bytes from localhost: frames=2 req=2 time=38.2ms opcode=0x05 >>> 120 bytes from localhost: frames=2 req=3 time=37.4ms opcode=0x05 >>> --- localhost websocket ping statistics using 1 connection --- >>> 9 frames transmitted, 6 received, 3 messages transmitted, 3 received, >>> time 3009ms rtt min/ave/max = 37.448/42.534/51.974 ms >>> >>> So 3x120B binary messages were sent in 3x40B fragments, for a total of >>> 9 frames sent. The echo-fragment protocol received these 3 messages >>> and echoed each back in 2 fragments, for 6 frames received. >>> >>> >>> cheers >>> >> _______________________________________________ >> 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 > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From salvatore.loreto@ericsson.com Wed Mar 16 05:48:56 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C63B3A68AD for ; Wed, 16 Mar 2011 05:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQmWP+VMeoUv for ; Wed, 16 Mar 2011 05:48:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 5573E3A67E1 for ; Wed, 16 Mar 2011 05:48:55 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-51-4d80b20caf30 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 54.5A.09202.C02B08D4; Wed, 16 Mar 2011 13:50:20 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Wed, 16 Mar 2011 13:50:20 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0ED6425C7; Wed, 16 Mar 2011 14:50:20 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C998750A02; Wed, 16 Mar 2011 14:50:19 +0200 (EET) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 78F724F3AA; Wed, 16 Mar 2011 14:50:19 +0200 (EET) Message-ID: <4D80B20B.4030208@ericsson.com> Date: Wed, 16 Mar 2011 14:50:19 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: Joe Hildebrand Subject: [hybi] preliminary agenda for Prague IETF 80 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 12:48:56 -0000 Hi all, The initial draft agenda of HyBi is available at: http://www.ietf.org/proceedings/80/agenda/hybi.txt please contact Joe and me for changes or missing requests. cheers /Sal -- Salvatore Loreto www.sloreto.com From salvatore.loreto@ericsson.com Wed Mar 16 07:46:10 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263273A6920 for ; Wed, 16 Mar 2011 07:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LC+qPLNyIuvd for ; Wed, 16 Mar 2011 07:46:09 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C14463A6911 for ; Wed, 16 Mar 2011 07:46:08 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-f7-4d80cd86f87c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 18.AC.09202.68DC08D4; Wed, 16 Mar 2011 15:47:34 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Wed, 16 Mar 2011 15:47:33 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 00D1E25C7 for ; Wed, 16 Mar 2011 16:47:34 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BEACD4EEA7 for ; Wed, 16 Mar 2011 16:47:33 +0200 (EET) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 81CD94EE8F for ; Wed, 16 Mar 2011 16:47:33 +0200 (EET) Message-ID: <4D80CD85.7080802@ericsson.com> Date: Wed, 16 Mar 2011 16:47:33 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [hybi] remote participation: meetecho tool X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 14:46:10 -0000 Hi there, for those who won't be physically present in Prague, but want to actively participate/interact to theHyBi session on Tuesday 29 March, 1300-1500 CET other that the usual way to remotely participate/interact (see http://www.ietf.org/meeting/80/remote-participation.html ) this time IETF RealTime Area is running an unofficial experiment with the following tool: http://conf.meetecho.com/ at moment I haven't received any request from people willing to participate/interact remotely so I haven't request yet support for meetecho neither for webex Let me know if you think it would be great to set up a meetecho/webex channel. anyway if you want participation remotely to the HyBi session, and you are not sure how, ask Joe and me privately. We will try to help you. cheers /Sal -- Salvatore Loreto www.sloreto.com From gregw@intalio.com Wed Mar 16 15:07:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B049B3A6A37 for ; Wed, 16 Mar 2011 15:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PWAjhL634vL for ; Wed, 16 Mar 2011 15:07:57 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 584373A6A16 for ; Wed, 16 Mar 2011 15:07:55 -0700 (PDT) Received: by vxg33 with SMTP id 33so2469694vxg.31 for ; Wed, 16 Mar 2011 15:09:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.175.104 with SMTP id bz8mr773370vdc.143.1300313361716; Wed, 16 Mar 2011 15:09:21 -0700 (PDT) Received: by 10.52.161.42 with HTTP; Wed, 16 Mar 2011 15:09:21 -0700 (PDT) In-Reply-To: <4D8012D6.40605@it.aoyama.ac.jp> References: <1299520117.2606.130.camel@ds9.ducksong.com> <4D7552FD.9090002@warmcat.com> <4D8012D6.40605@it.aoyama.ac.jp> Date: Thu, 17 Mar 2011 09:09:21 +1100 Message-ID: From: Greg Wilkins To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi , Gabriel Montenegro Subject: Re: [hybi] interop tests - fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 22:07:58 -0000 Martin, OK, I'll put my hand up to write a draft describing these test protocols. Probably take me a week to find the time. cheers On 16 March 2011 12:31, "Martin J. D=FCrst" wrote: > I agree with Gabriel. I think common subprotocols and common frameworks a= nd > patterns is something that will draw attention in the websockets area soo= n. > I think using the org.ietf.websocket label may be slightly premature, but= as > you have already used it, it's probably more confusing to change it, and > then again change it back. I also think that writing an Internet Draft ab= out > the test protocols would be a good idea. This can be an individual draft = and > later be adopted by the WG (if we think we have the protocol itself > sufficiently nailed down). Unfortunately, you have to wait two weeks for = the > submission to open again. > > Regards, =A0 =A0Martin. > > On 2011/03/16 8:27, Gabriel Montenegro wrote: >> >> I think this is a good idea. W3C has test suites for the APIs, but there >> is no equivalent for the protocol side at the IETF. This could be a way = to >> incorporate some standard tests. >> >>> -----Original Message----- >>> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of >>> Greg >>> Wilkins >>> Sent: Tuesday, March 15, 2011 16:20 >>> To: hybi >>> Subject: Re: [hybi] interop tests - fragments >>> >>> hmmmm =A0there is no chorus of approval for some common testing sub >>> protocols >>> - so unless anybody speaks up soon, I'll drop the org.ietf.websocket fr= om >>> the >>> protocols that jetty implements. >>> >>> cheers >>> >>> >>> On 15 March 2011 00:40, Greg Wilkins =A0wrote: >>>> >>>> Since not everybody doing interop will be familiar with Java, =A0I >>>> thought I'd post some more explicit instructions of how to run the >>>> jetty test client/server, plus descriptions of the test protocols that >>>> they are using. >>>> >>>> You can get the latest jetty aggregate jar with: >>>> =A0wget -O jetty-all.jar >>>> https://oss.sonatype.org/content/groups/jetty-with-staging/org/eclipse >>>> /jetty/aggregate/jetty-all/7.3.2-SNAPSHOT/jetty-all-7.3.2-20110314.133 >>>> 648-9.jar >>>> >>>> you also need a servlet jar: >>>> =A0wget --user-agent=3Dsomething >>>> http://repo2.maven.org/maven2/javax/servlet/servlet-api/2.5/servlet-ap >>>> i-2.5.jar >>>> >>>> >>>> The server can then be run with >>>> >>>> =A0java -cp jetty-all.jar:servlet-api-2.5.jar >>>> org.eclipse.jetty.websocket.TestServer --port 8080 >>>> >>>> >>>> And the client with: >>>> >>>> =A0java -cp jetty-all.jar:servlet-api-2.5.jar >>>> org.eclipse.jetty.websocket.TestClient --help >>>> =A0ERROR: [--help] >>>> =A0USAGE: java -cp CLASSPATH class >>>> org.eclipse.jetty.websocket.TestClient [ OPTIONS ] >>>> =A0 =A0-h|--host HOST =A0(default localhost) >>>> =A0 =A0-p|--port PORT =A0(default 8080) >>>> =A0 =A0-b|--binary >>>> =A0 =A0-v|--verbose >>>> =A0 =A0-c|--count n =A0 =A0(default 10) >>>> =A0 =A0-s|--size n =A0 =A0 (default 64) >>>> =A0 =A0-f|--fragment n (default 4000) >>>> =A0 =A0-P|--protocol echo|echo-assemble|echo-fragment|echo-broadcast >>>> >>>> >>>> The protocols supported are the ones I proposed earlier: >>>> >>>> =A0 =A0org.ietf.websocket.test-echo >>>> =A0 =A0 =A0 =A0Websocket messages are sent by the client and the serve= r will >>>> echo every frame. >>>> >>>> =A0 =A0org.ietf.websocket.test-echo-broadcast >>>> =A0 =A0 =A0 =A0Websocket messages are sent by the client and the serve= r will >>>> echo every frame to every connection. >>>> >>>> =A0 =A0org.ietf.websocket.test-echo-assemble >>>> =A0 =A0 =A0 =A0Websocket messages are sent by the client and the serve= r will >>>> echo assembled messages as a single frame. >>>> >>>> =A0 =A0org.ietf.websocket.test-echo-fragment >>>> =A0 =A0 =A0 =A0Websocket messages are sent and the server will echo ea= ch >>>> message fragmented into 2 frames. >>>> >>>> >>>> If there is no interest in making these common, then I'll drom the >>>> org.ietf prefix >>>> >>>> An example of running the test client is >>>> >>>> [558] java -cp jetty-all.jar:servlet-api-2.5.jar >>>> org.eclipse.jetty.websocket.TestClient --port 8080 --binary --count 3 >>>> --size 120 --fragment 40 --protocol echo-fragment Jetty WebSocket PING >>>> localhost:8080 (localhost/127.0.0.1:8080) 120 bytes of data. >>>> handshake OK for protocol 'org.ietf.websocket.test-echo-fragment' >>>> 120 bytes from localhost: frames=3D2 req=3D1 time=3D52.0ms opcode=3D0x= 05 >>>> 120 bytes from localhost: frames=3D2 req=3D2 time=3D38.2ms opcode=3D0x= 05 >>>> 120 bytes from localhost: frames=3D2 req=3D3 time=3D37.4ms opcode=3D0x= 05 >>>> --- localhost websocket ping statistics using 1 connection --- >>>> 9 frames transmitted, 6 received, 3 messages transmitted, 3 received, >>>> time 3009ms rtt min/ave/max =3D 37.448/42.534/51.974 ms >>>> >>>> So 3x120B binary messages were sent in 3x40B fragments, for a total of >>>> 9 frames sent. =A0The echo-fragment protocol received these 3 messages >>>> and echoed each back in 2 fragments, for 6 frames received. >>>> >>>> >>>> cheers >>>> >>> _______________________________________________ >>> 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 >> > > -- > #-# Martin J. D=FCrst, Professor, Aoyama Gakuin University > #-# http://www.sw.it.aoyama.ac.jp =A0 mailto:duerst@it.aoyama.ac.jp > From Martin.Thomson@commscope.com Thu Mar 17 21:13:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D333A69ED for ; Thu, 17 Mar 2011 21:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lvBKlnG3bYs for ; Thu, 17 Mar 2011 21:13:25 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 59DB33A69EB for ; Thu, 17 Mar 2011 21:13:25 -0700 (PDT) X-AuditID: 0a0404e9-b7ba5ae000000969-dc-4d82dc3d1ff7 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 14.79.02409.D3CD28D4; Thu, 17 Mar 2011 23:14:53 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 17 Mar 2011 23:14:52 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 18 Mar 2011 12:14:49 +0800 From: "Thomson, Martin" To: Mark Nottingham , Salvatore Loreto , Greg Wilkins Date: Fri, 18 Mar 2011 12:14:46 +0800 Thread-Topic: [hybi] Fwd: New Version Notification for draft-thomson-hybi-http-timeout-00 Thread-Index: AcvfSiAty4OijbsLSZ+DSu7cbQPNLQF0yVqA Message-ID: <8B0A9FCBB9832F43971E38010638454F0400BEFF60@SISPE7MB1.commscope.com> References: <4D776669.20300@ericsson.com> <98F23E74-AF00-4F38-968A-3B4CD40B8B3B@mnot.net> In-Reply-To: <98F23E74-AF00-4F38-968A-3B4CD40B8B3B@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org HTTP" Subject: Re: [hybi] Fwd: New Version Notification for draft-thomson-hybi-http-timeout-00 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 04:13:26 -0000 Hi Mark, Thanks for putting thought into this. This is exactly the sort of feedback= we need. On 2011-03-11 at 04:39:25, Mark Nottingham wrote: > Hey, >=20 > A couple of thoughts -- >=20 > I regularly am asked by devs for something like Request-Timeout,=20 > usually for enforcement on an intermediary, rather than the origin,=20 > but it's applicable there too. >=20 > I always resist it, because there's a race condition between the=20 > client's declared request time and its enforcement (as you know it). > It's better to just close the connection and enforce the timeout where=20 > it's declared; no matter how clearly you document that this is just=20 > advisory, many developers will look at request-timeout and immediately=20 > use it in place of a client-side timeout. >=20 > Do you have use cases for Request-Timeout that aren't covered by a=20 > client-side timeout? Since you ask, yes :) In a lot of scenarios, a simple client-side connection drop is going to be = sufficient. That's true for the case where responses arrive atomically - t= he classic comet use case. It is a little inefficient to drop the connection. After all, it's not alw= ays the case that the client really needs to drop the connection, maybe the= y just wanted to ask about something else instead. But that's not the case= that motivated this for me. I could see why you might reject a request fo= r a new header on those grounds alone - politeness alone is insufficient ju= stification. In the business that I work in - location - knowing how long you have to an= swer up front is considered quite valuable. A GPS receiver takes a certain= amount of time to start producing anything at all, and it's a pretty power= hungry beast. You don't even bother trying the GPS receiver unless you ha= ve some indication from your client that they are willing to wait for the r= esponse. If they don't have the time, you can choose a quicker method, lik= e round-trip timing or *waves hands* myriad other options. But each of tho= se location determination methods have their own limitations. Thus, it's not a case of just waiting until an atomic event occurs. It's a= bout setting down the request constraints up front. We can (and already do) set those constraints in requests in other ways. C= urrently, the best option we have is POST bodies, but you'll appreciate tha= t this doesn't interact well with other HTTP features. =20 > Regarding Connection-Timeout - I still think a simple indication that=20 > it's a long-lived request is more useful (and truthful), but=20 I was thinking that Request-Timeout would provide that bit of information i= ndicating the request being long-lived - after all, a connection header isn= 't going to make it onto the next hop. If that single bit is all you are l= ooking for, of course... Connection-Timeout / Keep-Alive still has value for a client who wants to r= euse a connection. Even without long-polling, they can use that informatio= n to determine whether or not to open a new connection for their POST reque= st. > if you=20 > are going to go down this road, you'll need to define 'idle' more=20 > carefully. I'll admit that the definition of 'idle' is a little casual, but is there a= nything fundamentally wrong with the idea that it is a) subjective b) based on either sending or receiving of data c) probably ignorant of buffering and any fancy TCP layer stuff (Nagle's a= lgorithm, etc, though that's hardly measurable at a granularity of seconds) > For example, Squid had the concept of a read timeout=20 > cache.org/Versions/v2/2.HEAD/cfgman/read_timeout.html>, which applies=20 > to connections with an outstanding request on them, but it also has a=20 > persistent request timeout cache.org/Versions/v2/2.HEAD/cfgman/persistent_request_timeout.html> > which applies to those that don't. How do they interact with=20 > Connection-TImeout? The intent is to combine the two. Each time that you send or receive data,= you reset the time. Given the configuration for Squid, you would have to = report the lower of these two. Note that with the default Squid configuration, you could report a 15min ti= me to servers and a 2min time to clients. That doesn't work so well for a = persistent server connection, since it doesn't appear like the read timeout= pays any attention to the fact that you are using the connection to send. = For instance, if you receive a new request just before the end of a 15 min= read idle, you might time out at 15 min despite the fact that the connecti= on might have been OK. (That's just me reading a lot into those descriptions alone, I didn't look = at the code...) --Martin From julian.reschke@gmx.de Fri Mar 18 03:13:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 813653A6A33 for ; Fri, 18 Mar 2011 03:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[AWL=-1.896, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+n+dsQmAhK5 for ; Fri, 18 Mar 2011 03:13:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id C428B3A68B7 for ; Fri, 18 Mar 2011 03:13:37 -0700 (PDT) Received: (qmail invoked by alias); 18 Mar 2011 10:15:04 -0000 Received: from p508FA8C7.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.168.199] by mail.gmx.net (mp018) with SMTP; 18 Mar 2011 11:15:04 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+IAvE5p+6Iji7HZt2CpJYdqv4Ha5dpX5UAfjF9PJ FwhXyozcaT1bHZ Message-ID: <4D8330A2.2020306@gmx.de> Date: Fri, 18 Mar 2011 11:14:58 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [hybi] Fwd: httpbis -13 drafts X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 10:13:39 -0000 FYI... The new drafts incorporate Connect/Upgrade from RFC 2817. See in particular: and Feedback on these particularly appreciated :-) Best regards, Julian -------- Original Message -------- Subject: httpbis -13 drafts Resent-Date: Mon, 14 Mar 2011 17:02:13 +0000 Resent-From: ietf-http-wg@w3.org Date: Mon, 14 Mar 2011 18:00:29 +0100 From: Julian Reschke To: HTTP Working Group Hi, I'm sure everybody noticed that drafts announcements a few minutes ago -- we just published the -13 drafts of Part 1 through 7 (today is the submission deadline before the Prague IETF meeting). In the -13 drafts we made good progress. Overviews are in the appendices: Among the changes are large rewrites in Part 1 and 2 (PUT method, for instance), plus the absorption of the RFC 2817 CONNECT/Upgrade feature. Mark Nottingham, our WG chair, will follow up with a list of tickets we'd link to close as fixed soonish. Feedback appreciated, Julian From Greg@ChampionEnt.net Fri Mar 18 11:27:47 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED38F3A69B7 for ; Fri, 18 Mar 2011 11:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4nhX8GURro6 for ; Fri, 18 Mar 2011 11:27:46 -0700 (PDT) Received: from smtpout-2.iphouse.net (smtpout-2.iphouse.net [209.240.70.141]) by core3.amsl.com (Postfix) with ESMTP id CE6B23A69D0 for ; Fri, 18 Mar 2011 11:27:45 -0700 (PDT) Received: from smtpout-2.iphouse.net (localhost [127.0.0.1]) by outbound-clamsmtpd.iphouse.net (Postfix) with ESMTP id 442691CDBE for ; Fri, 18 Mar 2011 13:29:15 -0500 (CDT) Received: from GJL8710w (office1.championent.net [216.160.45.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpout-2.iphouse.net (Postfix) with ESMTPSA id CE4A11CDAF for ; Fri, 18 Mar 2011 13:29:14 -0500 (CDT) From: "Greg Longtin" To: "hybi" Date: Fri, 18 Mar 2011 13:29:12 -0500 Message-ID: <000501cbe59a$62701cf0$275056d0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvlmmEq+uTKsn+YT2i3IjzMz+KQwQ== Content-Language: en-us X-Virus-Scanned: ClamAV using ClamSMTP Subject: [hybi] WebSocket & Nagle X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 18:49:56 -0000 To all, I have been working with WebSocket, based on it being a browser based socket interface for intranet use. I've created a Windows server, and have been testing with the MSFT 05 and 06 Silverlight prototypes and Pat McManus' WS 06 Minefield build (thank you.) I believe all three implementations allow the use of the Nagle algorithm for sending client packets. On my system, this intermittently introduces a 200 mS delay, along with the combining of packets. IMHO, for many applications, that amount of delay isn't acceptable. I'm not an Internet network type, so I'm not familiar with implications at that level. >From my perspective, it would be best if either Nagle was disabled for WebSocket packets, or the browser script API would allow one to do so. I realize that option is outside of hybi spec. Thanks, Greg From ifette@google.com Fri Mar 18 11:53:38 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE923A6999 for ; Fri, 18 Mar 2011 11:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.696 X-Spam-Level: X-Spam-Status: No, score=-105.696 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCfk0GeTTXy7 for ; Fri, 18 Mar 2011 11:53:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DBBE53A695C for ; Fri, 18 Mar 2011 11:53:37 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p2IIt6K1024861 for ; Fri, 18 Mar 2011 11:55:06 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1300474507; bh=EFt7vbnQDL43XeA6t7ybUtXnN2w=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=JwFEgwdytgKXgdlnU5kaGI4G8d2GGv+OZ3Hdq4ucUzCBKowZntUZwIaSagyztfAs4 QCfNQi0EqFduMjHJv7FnQ== Received: from iyi12 (iyi12.prod.google.com [10.241.51.12]) by hpaq11.eem.corp.google.com with ESMTP id p2IIso3G017308 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 18 Mar 2011 11:55:05 -0700 Received: by iyi12 with SMTP id 12so6266981iyi.17 for ; Fri, 18 Mar 2011 11:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vjUYarf9y26eAakAZUXcocOjxselTeu+NeaaOu5WyrU=; b=RrPCSGwECYsVbacfSsUqMGAT0eVDT1xMjEMtVnb2M9Jk7gx0/b1/+sC6z7t4tV23GU KQF+oRd0vFTx+cu03WMw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=wpBgxuWfOVLvWSMT7d+oedXV7Hix0wkDYyHrwjrW2R6fIy9IGp0sWW0PqXQVlEO9Kt eXGPOUff/3PcjNegAVIQ== MIME-Version: 1.0 Received: by 10.43.55.83 with SMTP id vx19mr2293567icb.24.1300474504658; Fri, 18 Mar 2011 11:55:04 -0700 (PDT) Received: by 10.231.34.131 with HTTP; Fri, 18 Mar 2011 11:55:04 -0700 (PDT) In-Reply-To: <000501cbe59a$62701cf0$275056d0$@net> References: <000501cbe59a$62701cf0$275056d0$@net> Date: Fri, 18 Mar 2011 11:55:04 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Greg Longtin Content-Type: multipart/alternative; boundary=bcaec517a9aee3c0a1049ec6501a X-System-Of-Record: true Cc: hybi Subject: Re: [hybi] WebSocket & Nagle X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 18:53:38 -0000 --bcaec517a9aee3c0a1049ec6501a Content-Type: text/plain; charset=UTF-8 in Chrome, we disable nagle fwiw. -ian On Fri, Mar 18, 2011 at 11:29 AM, Greg Longtin wrote: > To all, > > I have been working with WebSocket, based on it being a browser based > socket > interface for intranet use. > > I've created a Windows server, and have been testing with the MSFT 05 and > 06 > Silverlight prototypes and Pat McManus' WS 06 Minefield build (thank you.) > > I believe all three implementations allow the use of the Nagle algorithm > for > sending client packets. On my system, this intermittently introduces a 200 > mS delay, along with the combining of packets. IMHO, for many > applications, > that amount of delay isn't acceptable. > > I'm not an Internet network type, so I'm not familiar with implications at > that level. > > From my perspective, it would be best if either Nagle was disabled for > WebSocket packets, or the browser script API would allow one to do so. I > realize that option is outside of hybi spec. > > Thanks, > > Greg > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --bcaec517a9aee3c0a1049ec6501a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable in Chrome, we disable nagle fwiw.

-ian

On Fri, Mar 18, 2011 at 11:29 AM, Greg Longtin <Greg@championent.net> wrote:
To all,

I have been working with WebSocket, based on it being a browser based socke= t
interface for intranet use.

I've created a Windows server, and have been testing with the MSFT 05 a= nd 06
Silverlight prototypes and Pat McManus' WS 06 Minefield build (thank yo= u.)

I believe all three implementations allow the use of the Nagle algorithm fo= r
sending client packets. =C2=A0On my system, this intermittently introduces = a 200
mS delay, along with the combining of packets. =C2=A0IMHO, for many applica= tions,
that amount of delay isn't acceptable.

I'm not an Internet network type, so I'm not familiar with implicat= ions at
that level.

>From my perspective, it would be best if either Nagle was disabled for
WebSocket packets, or the browser script API would allow one to do so. =C2= =A0I
realize that option is outside of hybi spec.

Thanks,

Greg

_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--bcaec517a9aee3c0a1049ec6501a-- From andy.warmcat.com@googlemail.com Fri Mar 18 12:09:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE423A6A08 for ; Fri, 18 Mar 2011 12:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gI+-HN89lprc for ; Fri, 18 Mar 2011 12:09:12 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 9900B3A6999 for ; Fri, 18 Mar 2011 12:09:12 -0700 (PDT) Received: by wwa36 with SMTP id 36so3532455wwa.13 for ; Fri, 18 Mar 2011 12:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2xLnHiGRAUXY+N4ieAyTGRvLiioXYBU1RvBMLa3PWjU=; b=Ftk4++9Pgo5eYEByeVe/fAcolZOqdPJGJhjmzXwwv/ybITORe0civf2Ix1tT5YR6Vv R/umd3jXrTSjvbqyeXkSNMxT87IFU1zw2ECV3XLi73veaTvx1m6Y6fMecBikgbCEb+Ps h/F5uxZ5FBhlM5HWQNIzYtVfdrhlC4cE3RzuY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=WuwDJpv0n7uB546BOsHXXIc8SFBaCtgHGDgnJUqhm0NuowG98CjRtz4NtzbJUctj+R aVuVIMn4pn8FjvDoNrJ7j1PCrwylhSEuUxfA2FoLWi3A5zMcfVdN/NTwl/EHKQxXx60n E2OKuovC4JP29Qe5ozvDkQk0WX4fCJYVRsC+4= Received: by 10.227.196.2 with SMTP id ee2mr1557486wbb.129.1300475441320; Fri, 18 Mar 2011 12:10:41 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id bd8sm1504312wbb.35.2011.03.18.12.10.39 (version=SSLv3 cipher=OTHER); Fri, 18 Mar 2011 12:10:40 -0700 (PDT) Sender: Andy Green Message-ID: <4D83AE2E.7080008@warmcat.com> Date: Fri, 18 Mar 2011 19:10:38 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110310 Fedora/3.1.9-2.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Longtin References: <000501cbe59a$62701cf0$275056d0$@net> In-Reply-To: <000501cbe59a$62701cf0$275056d0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi Subject: Re: [hybi] WebSocket & Nagle X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 19:09:14 -0000 On 03/18/2011 06:29 PM, Somebody in the thread at some point said: Hi - > I have been working with WebSocket, based on it being a browser based socket > interface for intranet use. > > I've created a Windows server, and have been testing with the MSFT 05 and 06 > Silverlight prototypes and Pat McManus' WS 06 Minefield build (thank you.) > > I believe all three implementations allow the use of the Nagle algorithm for > sending client packets. On my system, this intermittently introduces a 200 > mS delay, along with the combining of packets. IMHO, for many applications, > that amount of delay isn't acceptable. > > I'm not an Internet network type, so I'm not familiar with implications at > that level. > > From my perspective, it would be best if either Nagle was disabled for > WebSocket packets, or the browser script API would allow one to do so. I > realize that option is outside of hybi spec. libwebsockets also kills Nagling. Nagle can lead to what is basically 5Hz service which is "not the right thing". -Andy From Gabriel.Montenegro@microsoft.com Fri Mar 18 12:25:30 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 115D93A68BD for ; Fri, 18 Mar 2011 12:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.508 X-Spam-Level: X-Spam-Status: No, score=-10.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8eCAK2RCG2C for ; Fri, 18 Mar 2011 12:25:29 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id F2D923A68F9 for ; Fri, 18 Mar 2011 12:25:28 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 18 Mar 2011 12:26:58 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.270.2; Fri, 18 Mar 2011 12:26:58 -0700 Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.217]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Fri, 18 Mar 2011 12:26:57 -0700 From: Gabriel Montenegro To: Andy Green , Greg Longtin Thread-Topic: [hybi] WebSocket & Nagle Thread-Index: AcvlmmEq+uTKsn+YT2i3IjzMz+KQwQAQHWoAAA4rOuA= Date: Fri, 18 Mar 2011 19:26:57 +0000 Message-ID: References: <000501cbe59a$62701cf0$275056d0$@net> <4D83AE2E.7080008@warmcat.com> In-Reply-To: <4D83AE2E.7080008@warmcat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: hybi Subject: Re: [hybi] WebSocket & Nagle X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 19:25:30 -0000 > > From my perspective, it would be best if either Nagle was disabled for > > WebSocket packets, or the browser script API would allow one to do so. = I > > realize that option is outside of hybi spec. >=20 > libwebsockets also kills Nagling. Nagle can lead to what is basically > 5Hz service which is "not the right thing". As for the general issue, while it is true that the JS API applications mig= ht mostly benefit from turning off Nagle, the protocol goes beyond the JS A= PI, e.g., with capabilities like binary and streaming. Given the generality= of the protocol, I don't think the specification itself can mandate one wa= y or another, similar to how TCP itself cannot mandate one way or another. = But having a default, and a way to change it makes sense. From mcmanus@ducksong.com Fri Mar 18 12:50:01 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958B13A6926 for ; Fri, 18 Mar 2011 12:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aImEvCAY5aFw for ; Fri, 18 Mar 2011 12:50:00 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 96B753A691D for ; Fri, 18 Mar 2011 12:50:00 -0700 (PDT) Received: by linode.ducksong.com (Postfix, from userid 1000) id 71540102A7; Fri, 18 Mar 2011 15:51:27 -0400 (EDT) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 31F7110159; Fri, 18 Mar 2011 15:51:23 -0400 (EDT) From: "Pat McManus @Mozilla" To: Greg Longtin In-Reply-To: <000501cbe59a$62701cf0$275056d0$@net> References: <000501cbe59a$62701cf0$275056d0$@net> Content-Type: text/plain; charset="UTF-8" Date: Fri, 18 Mar 2011 15:50:11 -0400 Message-ID: <1300477811.2965.2278.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: hybi Subject: Re: [hybi] WebSocket & Nagle X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 19:50:01 -0000 On Fri, 2011-03-18 at 13:29 -0500, Greg Longtin wrote: > To all, > > I have been working with WebSocket, based on it being a browser based socket > interface for intranet use. > > I've created a Windows server, and have been testing with the MSFT 05 and 06 > Silverlight prototypes and Pat McManus' WS 06 Minefield build (thank you.) > its true the minefield build had nagle enabled because it only had the websocket patch included.. but in our patch tracker the websockets patch already depends on another one that disables nagle - so a real build won't go out the door without it. though as gabriel notes there are certainly some applications (e.g. one keystroke per msg) that should work the other way and I'd be happy with an API to address it. -- http://www.getfirefox.com/ From mnot@mnot.net Sun Mar 20 19:20:07 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FF628C10A for ; Sun, 20 Mar 2011 19:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.414 X-Spam-Level: X-Spam-Status: No, score=-105.414 tagged_above=-999 required=5 tests=[AWL=-2.815, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQCUpnXT33wW for ; Sun, 20 Mar 2011 19:20:01 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 3DA2C28C10B for ; Sun, 20 Mar 2011 19:20:00 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.52.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0599F509D9; Sun, 20 Mar 2011 22:21:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0400BEFF60@SISPE7MB1.commscope.com> Date: Mon, 21 Mar 2011 13:21:24 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D776669.20300@ericsson.com> <98F23E74-AF00-4F38-968A-3B4CD40B8B3B@mnot.net> <8B0A9FCBB9832F43971E38010638454F0400BEFF60@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1082) Cc: "hybi@ietf.org HTTP" Subject: Re: [hybi] Fwd: New Version Notification for draft-thomson-hybi-http-timeout-00 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 02:20:07 -0000 On 18/03/2011, at 3:14 PM, Thomson, Martin wrote: >>=20 >> Do you have use cases for Request-Timeout that aren't covered by a=20 >> client-side timeout? >=20 > Since you ask, yes :) >=20 > In a lot of scenarios, a simple client-side connection drop is going = to be sufficient. That's true for the case where responses arrive = atomically - the classic comet use case. >=20 > It is a little inefficient to drop the connection. After all, it's = not always the case that the client really needs to drop the connection, = maybe they just wanted to ask about something else instead. =20 I don't see how request-timeout helps here; you seem to be saying that = the client can assume that it's OK after request-timeout seconds to = submit a new request on the connection, and assume that the old request = has been "cancelled" server-side. That fundamentally doesn't work. Its true that there's ambiguity between purposeful connection drop and = accidental (e.g., network-related) drop. However, it seems to me that = using timeouts is a very bad way to detect this. Why not send a request = explicitly saying that you're dropping the connection instead? E.g., OPTIONS * HTTP/1.1 Expect: im-outta-here-and-i-mean-it That's just one way, there are lots of others (e.g., a chunk-extension). > In the business that I work in - location - knowing how long you have = to answer up front is considered quite valuable. A GPS receiver takes a = certain amount of time to start producing anything at all, and it's a = pretty power hungry beast. You don't even bother trying the GPS = receiver unless you have some indication from your client that they are = willing to wait for the response. If they don't have the time, you can = choose a quicker method, like round-trip timing or *waves hands* myriad = other options. But each of those location determination methods have = their own limitations. >=20 > Thus, it's not a case of just waiting until an atomic event occurs. = It's about setting down the request constraints up front. Ah -- OK, that's an interesting use case. I didn't get that from the = draft.=20 This smells a little bit like the Prefer header: http://tools.ietf.org/html/draft-snell-http-prefer-02 Did you consider using something like that? E.g.,=20 Prefer: response-fast Where the parameters of 'response-fast' is specific to the resource. As you can probably guess, I'm suggesting this because I'm concerned = that 95% of people who want to use something like Request-Timeout won't = have such a subtle use case in mind. >> if you=20 >> are going to go down this road, you'll need to define 'idle' more=20 >> carefully. >=20 > I'll admit that the definition of 'idle' is a little casual, but is = there anything fundamentally wrong with the idea that it is > a) subjective > b) based on either sending or receiving of data > c) probably ignorant of buffering and any fancy TCP layer stuff = (Nagle's algorithm, etc, though that's hardly measurable at a = granularity of seconds) It depends very much on how it's used by receiving software. Your points = only emphasise how little real information there is in the number that's = getting transmitted... -- Mark Nottingham http://www.mnot.net/ From Martin.Thomson@commscope.com Sun Mar 20 21:19:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4C33A65A5 for ; Sun, 20 Mar 2011 21:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.935 X-Spam-Level: X-Spam-Status: No, score=-2.935 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhYcO7e3Wl7G for ; Sun, 20 Mar 2011 21:19:47 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 9A4803A6405 for ; Sun, 20 Mar 2011 21:19:47 -0700 (PDT) X-AuditID: 0a0404e8-b7b25ae000007eb9-97-4d86d23e23e1 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id DE.95.32441.E32D68D4; Sun, 20 Mar 2011 23:21:19 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Sun, 20 Mar 2011 23:21:18 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 21 Mar 2011 12:21:13 +0800 From: "Thomson, Martin" To: Mark Nottingham Date: Mon, 21 Mar 2011 12:21:11 +0800 Thread-Topic: [hybi] Fwd: New Version Notification for draft-thomson-hybi-http-timeout-00 Thread-Index: AcvnbsnDbbfXNduMSQ6rxritc6NFPgAByD0w Message-ID: <8B0A9FCBB9832F43971E38010638454F0400BF01A2@SISPE7MB1.commscope.com> References: <4D776669.20300@ericsson.com> <98F23E74-AF00-4F38-968A-3B4CD40B8B3B@mnot.net> <8B0A9FCBB9832F43971E38010638454F0400BEFF60@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org HTTP" Subject: Re: [hybi] Fwd: New Version Notification for draft-thomson-hybi-http-timeout-00 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 04:19:48 -0000 On 2011-03-21 at 13:21:24, Mark Nottingham wrote: > On 18/03/2011, at 3:14 PM, Thomson, Martin wrote: > > It is a little inefficient to drop the connection. After all, it's > not always the case that the client really needs to drop the=20 > connection, maybe they just wanted to ask about something else instead. >=20 > I don't see how request-timeout helps here; you seem to be saying that=20 > the client can assume that it's OK after request-timeout seconds to=20 > submit a new request on the connection, and assume that the old=20 > request has been "cancelled" server-side. That fundamentally doesn't work= . That's not the intent. I assume that if the server knows request-timeout, = then they are able to send an error response at that time, making the conne= ction available. Obviously, if the client sends another request after that= time, they are effectively pipelining...with all that entails. =20 > Its true that there's ambiguity between purposeful connection drop and=20 > accidental (e.g., network-related) drop. However, it seems to me that=20 > using timeouts is a very bad way to detect this.=20 The draft talks about that. There will always be a need to handle lost con= nections. Timeouts can't help, and we wouldn't pretend that they would. > Why not send a=20 > request explicitly saying that you're dropping the connection instead?=20 > E.g., >=20 > OPTIONS * HTTP/1.1 > Expect: im-outta-here-and-i-mean-it >=20 > That's just one way, there are lots of others (e.g., a chunk-=20 > extension). I don't see how that would help at all. > > In the business that I work in - location - knowing how long you=20 > > have > to answer up front is considered quite valuable. A GPS receiver takes=20 > a certain amount of time to start producing anything at all, and it's=20 > a pretty power hungry beast. You don't even bother trying the GPS=20 > receiver unless you have some indication from your client that they=20 > are willing to wait for the response. If they don't have the time,=20 > you can choose a quicker method, like round-trip timing or *waves=20 > hands* myriad other options. But each of those location determination=20 > methods have their own limitations. > > > > Thus, it's not a case of just waiting until an atomic event occurs. > It's about setting down the request constraints up front. >=20 > Ah -- OK, that's an interesting use case. I didn't get that from the=20 > draft. >=20 > This smells a little bit like the Prefer header: > http://tools.ietf.org/html/draft-snell-http-prefer-02 > =09 > Did you consider using something like that? E.g., > Prefer: response-fast >=20 > Where the parameters of 'response-fast' is specific to the resource. Interesting thought, but ultimately it ends up with the same semantics of r= equest-timeout: Prefer: response-within=3D10 A single bit doesn't quite suffice for this use case. While there is some = value in being able to choose between the slowest and the fastest response,= that precludes a range of in-between options. > As you can probably guess, I'm suggesting this because I'm concerned=20 > that 95% of people who want to use something like Request-Timeout=20 > won't have such a subtle use case in mind. And if that's the case, that's a good reason not to define a new header and= look for other options (like Prefer). > >> if you > >> are going to go down this road, you'll need to define 'idle' more=20 > >> carefully. > > > > I'll admit that the definition of 'idle' is a little casual, but is=20 > > there anything fundamentally wrong with the idea that it is > > a) subjective > > b) based on either sending or receiving of data > > c) probably ignorant of buffering and any fancy TCP layer stuff=20 > > (Nagle's algorithm, etc, though that's hardly measurable at a=20 > > granularity of seconds) >=20 > It depends very much on how it's used by receiving software. Your=20 > points only emphasise how little real information there is in the=20 > number that's getting transmitted... It is a promise to a peer that they wont close the connection until they th= ink the connection is idle (as above) for the specified time, exceptional c= ircumstances excepted. For instance, a client that sees a value of 120 might choose to reuse a con= nection that is (subjectively) idle for 90s. Whether they also reuse the c= onnection at 100, 110 and 119 is up to implementation/local configuration/o= ther unspecified heuristics. --Martin From Greg@ChampionEnt.net Mon Mar 21 06:17:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A0203A685D for ; Mon, 21 Mar 2011 06:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxNfwE38VtlL for ; Mon, 21 Mar 2011 06:17:33 -0700 (PDT) Received: from smtpout-2.iphouse.net (smtpout-2.iphouse.net [209.240.70.141]) by core3.amsl.com (Postfix) with ESMTP id AE6E13A685A for ; Mon, 21 Mar 2011 06:17:33 -0700 (PDT) Received: from smtpout-2.iphouse.net (localhost [127.0.0.1]) by outbound-clamsmtpd.iphouse.net (Postfix) with ESMTP id 21E361CD26 for ; Mon, 21 Mar 2011 08:19:05 -0500 (CDT) Received: from GJL8710w (longtin.dsl.visi.com [209.98.144.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpout-2.iphouse.net (Postfix) with ESMTPSA id BFF911CD13 for ; Mon, 21 Mar 2011 08:19:04 -0500 (CDT) From: "Greg Longtin" To: "hybi" Date: Mon, 21 Mar 2011 08:19:03 -0500 Message-ID: <001701cbe7ca$8d345be0$a79d13a0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvnyoyhTIdkCtEHT9CALrmDK5v+hA== Content-Language: en-us X-Virus-Scanned: ClamAV using ClamSMTP Subject: [hybi] WS & Nagle in use X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 13:17:34 -0000 To all, Good day. Previously, I asked that WS should disable Nagle, or the API might allow control of it. This weekend I thought of the converse. Not being familiar with all OS's, I'm not sure if, now or in the future, administrative control may affect whether Nagle can be controlled at an app level. Hence, should the specs state clearly that if a server or client WS application receives a 'multiple message' Nagle packet, that all messages should be decoded from it? In my testing, I'm not sure if the current clients did so. Should I test the Minefield and Silverlight implementations, or are we certain that they do so? Thanks, Greg From andy.warmcat.com@googlemail.com Mon Mar 21 06:28:06 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4506628C13E for ; Mon, 21 Mar 2011 06:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.623 X-Spam-Level: X-Spam-Status: No, score=-3.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT3H-yzjQgi9 for ; Mon, 21 Mar 2011 06:28:02 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 724FF28C13A for ; Mon, 21 Mar 2011 06:28:02 -0700 (PDT) Received: by wwa36 with SMTP id 36so4950460wwa.13 for ; Mon, 21 Mar 2011 06:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OHbLn3Mi/pBPIWZlRfZzBmd2TWq9IUi0yXvOI/6EG/M=; b=JaB8D7q1DKDsNSTyuhNpetPNu4mx9v0djrha3Jc179yZR9n9wsyDr/bFeQiIQ+7ZCH Qrw5k60RorTmqFd58EDWJ1F/HNd9Vn/J0bOZ/AUB2dERhnmZdsyCMDKuw3LLnM9767We Y7FLPK59ZxekKdvz2DnXohjkVKXmFnmNt8vsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=IIsdXuBcjqE33/iuUhN+/haDe5uRqARiOikZQi27mMjOh15bWQmldrswhdq89I/wL6 ynJNduuYDqW05wcdyqt+FmrGdGoqeEYSZv/te0XsBwIg2D/lcv0XTMwhIoXSaAuU6R+O duy2oZnD6N2k/Uj0WAmbH4XPB4jnjDBYBzd1M= Received: by 10.216.229.4 with SMTP id g4mr5620501weq.54.1300714174304; Mon, 21 Mar 2011 06:29:34 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id w25sm2756522wbd.39.2011.03.21.06.29.33 (version=SSLv3 cipher=OTHER); Mon, 21 Mar 2011 06:29:33 -0700 (PDT) Sender: Andy Green Message-ID: <4D8752BC.3000704@warmcat.com> Date: Mon, 21 Mar 2011 13:29:32 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110310 Fedora/3.1.9-2.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Longtin References: <001701cbe7ca$8d345be0$a79d13a0$@net> In-Reply-To: <001701cbe7ca$8d345be0$a79d13a0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi Subject: Re: [hybi] WS & Nagle in use X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 13:28:06 -0000 On 03/21/2011 01:19 PM, Somebody in the thread at some point said: Hi - > Good day. Previously, I asked that WS should disable Nagle, or the API > might allow control of it. This weekend I thought of the converse. > > Not being familiar with all OS's, I'm not sure if, now or in the future, > administrative control may affect whether Nagle can be controlled at an app > level. > > Hence, should the specs state clearly that if a server or client WS > application receives a 'multiple message' Nagle packet, that all messages > should be decoded from it? I think it must handle this anyway because some other box between you and the client might choose to batch them up into a single packet for whatever reason. > In my testing, I'm not sure if the current clients did so. Should I test > the Minefield and Silverlight implementations, or are we certain that they > do so? libwebsockets does handle the whole parsing bytewise without reference to packet boundaries, but we had a user that found some windows machines triggered this 5Hz nagling business. Everything continued to work on other clients at the same time and even on those nagled clients, just the latency turned to crap for them. -Andy From mcmanus@ducksong.com Mon Mar 21 06:32:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5202F28C141 for ; Mon, 21 Mar 2011 06:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ1aEkzXtMDG for ; Mon, 21 Mar 2011 06:32:58 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 865DE28C140 for ; Mon, 21 Mar 2011 06:32:58 -0700 (PDT) Received: by linode.ducksong.com (Postfix, from userid 1000) id AD93B102A9; Mon, 21 Mar 2011 09:34:30 -0400 (EDT) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 1CED6102A6; Mon, 21 Mar 2011 09:34:26 -0400 (EDT) From: Patrick McManus To: Greg Longtin In-Reply-To: <001701cbe7ca$8d345be0$a79d13a0$@net> References: <001701cbe7ca$8d345be0$a79d13a0$@net> Content-Type: text/plain; charset="UTF-8" Date: Mon, 21 Mar 2011 09:34:22 -0400 Message-ID: <1300714462.2445.35.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: hybi Subject: Re: [hybi] WS & Nagle in use X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 13:32:59 -0000 On Mon, 2011-03-21 at 08:19 -0500, Greg Longtin wrote: > Hence, should the specs state clearly that if a server or client WS > application receives a 'multiple message' Nagle packet, that all messages > should be decoded from it? > TCP is a byte stream protocol - a single WS message might span multiple tcp packets with just 1 data byte in each, or it might be carried with thousands of other WS messages in a single TCP segment which itself is fragmented across multiple IP packets. Or of course there might be 1 websocket message per TCP segment. Websockets cannot restrict those options in any way, and receivers must deal with it (firefox included, because you asked.). The TCP API is bytestream based - it doesn't give reliable insight into how the data was arranged when it arrived. That doesn't really have much to do with nagle. You might see coalescing due to TCP congestion control delays or network driver scheduling delays or any number of other various indeterminate things. > In my testing, I'm not sure if the current clients did so. Should I test > the Minefield and Silverlight implementations, or are we certain that they > do so? > From mnot@mnot.net Mon Mar 21 18:17:29 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8F428C1C8 for ; Mon, 21 Mar 2011 18:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.365 X-Spam-Level: X-Spam-Status: No, score=-105.365 tagged_above=-999 required=5 tests=[AWL=-2.766, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXxhAQxRi0qV for ; Mon, 21 Mar 2011 18:17:28 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 2E98628C1C4 for ; Mon, 21 Mar 2011 18:17:28 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.52.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8E2AA509E2; Mon, 21 Mar 2011 21:18:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0400BF01A2@SISPE7MB1.commscope.com> Date: Tue, 22 Mar 2011 12:18:50 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <6B460F94-3138-4C41-A04A-0DC8AADBB2D1@mnot.net> References: <4D776669.20300@ericsson.com> <98F23E74-AF00-4F38-968A-3B4CD40B8B3B@mnot.net> <8B0A9FCBB9832F43971E38010638454F0400BEFF60@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F0400BF01A2@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1082) Cc: "hybi@ietf.org HTTP" Subject: Re: [hybi] Fwd: New Version Notification for draft-thomson-hybi-http-timeout-00 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 01:17:29 -0000 On 21/03/2011, at 3:21 PM, Thomson, Martin wrote: > On 2011-03-21 at 13:21:24, Mark Nottingham wrote: >> On 18/03/2011, at 3:14 PM, Thomson, Martin wrote: >>> It is a little inefficient to drop the connection. After all, it's >> not always the case that the client really needs to drop the=20 >> connection, maybe they just wanted to ask about something else = instead. >>=20 >> I don't see how request-timeout helps here; you seem to be saying = that=20 >> the client can assume that it's OK after request-timeout seconds to=20= >> submit a new request on the connection, and assume that the old=20 >> request has been "cancelled" server-side. That fundamentally doesn't = work. >=20 > That's not the intent. I assume that if the server knows = request-timeout, then they are able to send an error response at that = time, making the connection available. Obviously, if the client sends = another request after that time, they are effectively pipelining...with = all that entails. OK. That needs to be specified, then (or at least illustrated). >> Why not send a=20 >> request explicitly saying that you're dropping the connection = instead?=20 >> E.g., >>=20 >> OPTIONS * HTTP/1.1 >> Expect: im-outta-here-and-i-mean-it >>=20 >> That's just one way, there are lots of others (e.g., a chunk-=20 >> extension). >=20 > I don't see how that would help at all. I thought you were concerned about differentiating between intentional = and unintentional client connection drops. If not, no worries. >> Ah -- OK, that's an interesting use case. I didn't get that from the=20= >> draft. >>=20 >> This smells a little bit like the Prefer header: >> http://tools.ietf.org/html/draft-snell-http-prefer-02 >> =09 >> Did you consider using something like that? E.g., >> Prefer: response-fast >>=20 >> Where the parameters of 'response-fast' is specific to the resource. >=20 > Interesting thought, but ultimately it ends up with the same semantics = of request-timeout: > Prefer: response-within=3D10 >=20 > A single bit doesn't quite suffice for this use case. While there is = some value in being able to choose between the slowest and the fastest = response, that precludes a range of in-between options. response-within seems much more reasonable.=20 Cheers, -- Mark Nottingham http://www.mnot.net/ From Greg@ChampionEnt.net Sat Mar 26 06:33:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422D028C119 for ; Sat, 26 Mar 2011 06:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eny-rUQMLf0m for ; Sat, 26 Mar 2011 06:33:50 -0700 (PDT) Received: from smtpout-2.iphouse.net (smtpout-2.iphouse.net [209.240.70.141]) by core3.amsl.com (Postfix) with ESMTP id 4F81528C11C for ; Sat, 26 Mar 2011 06:33:49 -0700 (PDT) Received: from smtpout-2.iphouse.net (localhost [127.0.0.1]) by outbound-clamsmtpd.iphouse.net (Postfix) with ESMTP id DC4841CCDA for ; Sat, 26 Mar 2011 08:35:24 -0500 (CDT) Received: from GJL8710w (longtin.dsl.visi.com [209.98.144.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpout-2.iphouse.net (Postfix) with ESMTPSA id 82B201CCA8 for ; Sat, 26 Mar 2011 08:35:24 -0500 (CDT) From: "Greg Longtin" To: "hybi" Date: Sat, 26 Mar 2011 08:35:23 -0500 Message-ID: <000201cbebba$a9375010$fba5f030$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvruqiDovxyIwb/RV6ujwnTh+Ak4Q== Content-Language: en-us X-Virus-Scanned: ClamAV using ClamSMTP Subject: [hybi] WebSocket & HTTP Keep-Alive X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 13:33:51 -0000 To all, Good day. I don't want to use the term socket, so I'll define a channel as a unique server ip:port and a client ip:port pair. With HTTP Keep-Alive, these channels may stay open after a HTTP request / response, creating a (short term) group of channels. The WS specs do not seem to address whether client can use an existing open HTTP channel to begin a persistent WS connection. Similarly, once a WS channel is open, can a client use it for a HTTP request? >From an abstract perspective, who cares. From the perspective of server implementation, it gets interesting in terms of closing Keep-Alive connections and who listens to what. Simply put, it complicates things a bit. This issue is only a problem when both HTTP and WS are on the same (server) port. If I haven't read the specs well enough, please accept my apology. BTW, in a past job I dealt with contracts between somewhat unfriendly parties. Greg Longtin From w@1wt.eu Sat Mar 26 15:46:05 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB22A3A697A for ; Sat, 26 Mar 2011 15:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=-0.503, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EU0IadKXfrb for ; Sat, 26 Mar 2011 15:46:04 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 5ADBE3A6765 for ; Sat, 26 Mar 2011 15:46:03 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p2QMlUqG002823; Sat, 26 Mar 2011 23:47:30 +0100 Date: Sat, 26 Mar 2011 23:47:30 +0100 From: Willy Tarreau To: Greg Longtin Message-ID: <20110326224730.GC32397@1wt.eu> References: <000201cbebba$a9375010$fba5f030$@net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000201cbebba$a9375010$fba5f030$@net> User-Agent: Mutt/1.4.2.3i Cc: hybi Subject: Re: [hybi] WebSocket & HTTP Keep-Alive X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 22:46:05 -0000 Hi, On Sat, Mar 26, 2011 at 08:35:23AM -0500, Greg Longtin wrote: > The WS specs do not seem to address whether client can use an existing open > HTTP channel to begin a persistent WS connection. There is nothing which prevents that, because the server switches to the WS protocol upon a perfectly valid HTTP/1.1 request, and nothing dictates that this request must be the first one of a connection. > Similarly, once a WS > channel is open, can a client use it for a HTTP request? No this is not possible, because HTTP offers provisions for upgrading the HTTP protocol to something else, but there is nothing to do the opposite. In practice, what will happen is that most components will switch from HTTP to raw TCP and will not inspect the stream any further, so most of them will not be able to switch back to HTTP. Thus, even if we wanted to do that, it would be very dangerous to do so because we could have large combinations of undesired states between the intermediaries which are able to switch back and the other ones. > From an abstract perspective, who cares. From the perspective of server > implementation, it gets interesting in terms of closing Keep-Alive > connections and who listens to what. Simply put, it complicates things a > bit. On the server side it should not be an issue at all, since every HTTP requests are independant within a connection, so there should be no reason why something which can be done in the first request could not be done in the second or third. > This issue is only a problem when both HTTP and WS are on the same (server) > port. > > If I haven't read the specs well enough, please accept my apology. I don't think so, it's possible that some points on the subject would still merit some clarifying depending on the audience's experience with various practices. Regards, Willy From fielding@gbiv.com Sat Mar 26 21:42:37 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948503A6884 for ; Sat, 26 Mar 2011 21:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUJMZ2Z9Buop for ; Sat, 26 Mar 2011 21:42:36 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 267773A67E2 for ; Sat, 26 Mar 2011 21:42:36 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id B37DA5406F; Sat, 26 Mar 2011 21:44:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=YLwu1G898a88if3/ sP91IuduG+gD9nOlXamcoa6jiAoXHMuLt0Sr1wp5EF3iArlmX4jfp53TNyib4pbU 9FwVic9/+AhjwlTLCz1HFALFhJmJgQ51PGrcsiNl/UAI0Ux+SdOZFo93gtXxqMZo UrYhqONCvpGODg7NNRUiep/16aw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=+sJbV6CkjqyU0PALxV7mREyfyN0=; b=dhcW7HpP2v6FiV8utH6msjqVUzF8 aGITLIE2kwNHFIWfPxNcGsDPUtQNYX4eugX1Y7izynUecrGhZ2H/R6u7EEnoJumF i1aW++vCGDLxM8iqhnu73bKacbZUwANjQ6a0iATOCqfyXASKxipB/he1OZDdPgyD b3B//JeIynv2lWo= Received: from [192.168.222.66] (unknown [109.107.209.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id D6C415405B; Sat, 26 Mar 2011 21:44:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <20110326224730.GC32397@1wt.eu> Date: Sun, 27 Mar 2011 06:44:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000201cbebba$a9375010$fba5f030$@net> <20110326224730.GC32397@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1084) Cc: hybi , Greg Longtin Subject: Re: [hybi] WebSocket & HTTP Keep-Alive X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 04:42:37 -0000 On Mar 26, 2011, at 11:47 PM, Willy Tarreau wrote: > On Sat, Mar 26, 2011 at 08:35:23AM -0500, Greg Longtin wrote: >> The WS specs do not seem to address whether client can use an = existing open >> HTTP channel to begin a persistent WS connection. >=20 > There is nothing which prevents that, because the server switches to > the WS protocol upon a perfectly valid HTTP/1.1 request, and nothing > dictates that this request must be the first one of a connection. >=20 >> Similarly, once a WS >> channel is open, can a client use it for a HTTP request? >=20 > No this is not possible, because HTTP offers provisions for upgrading > the HTTP protocol to something else, but there is nothing to do the > opposite. It is possible if WS defines some way to do it, like Upgrade is defined for HTTP. It would require strict framing to prevent applications from taking control of that feature for MITM attacks. ....Roy= From w@1wt.eu Sat Mar 26 23:16:52 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEFC23A69A1 for ; Sat, 26 Mar 2011 23:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=-0.493, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XC9j-XylEH7O for ; Sat, 26 Mar 2011 23:16:52 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 919E53A699F for ; Sat, 26 Mar 2011 23:16:50 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p2R6IGqh003482; Sun, 27 Mar 2011 08:18:16 +0200 Date: Sun, 27 Mar 2011 08:18:16 +0200 From: Willy Tarreau To: "Roy T. Fielding" Message-ID: <20110327061816.GD32397@1wt.eu> References: <000201cbebba$a9375010$fba5f030$@net> <20110326224730.GC32397@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hybi , Greg Longtin Subject: Re: [hybi] WebSocket & HTTP Keep-Alive X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 06:16:52 -0000 On Sun, Mar 27, 2011 at 06:44:09AM +0200, Roy T. Fielding wrote: > On Mar 26, 2011, at 11:47 PM, Willy Tarreau wrote: > > On Sat, Mar 26, 2011 at 08:35:23AM -0500, Greg Longtin wrote: > >> The WS specs do not seem to address whether client can use an existing open > >> HTTP channel to begin a persistent WS connection. > > > > There is nothing which prevents that, because the server switches to > > the WS protocol upon a perfectly valid HTTP/1.1 request, and nothing > > dictates that this request must be the first one of a connection. > > > >> Similarly, once a WS > >> channel is open, can a client use it for a HTTP request? > > > > No this is not possible, because HTTP offers provisions for upgrading > > the HTTP protocol to something else, but there is nothing to do the > > opposite. > > It is possible if WS defines some way to do it, like Upgrade is > defined for HTTP. But HTTP-only intermediaries which will have upgrade and don't specifically know about WS won't be aware that WS wants to go back to HTTP, thus they'll remain in their raw TCP mode. This can be quite dangerous because this could allow the last server to receive HTTP traffic for a site it isn't, or without the expected intermediary control, switching or URL filtering. > It would require strict framing to prevent > applications from taking control of that feature for MITM attacks. Indeed, and I really think that the advantage of being able to switch back to HTTP after an Upgrade has succeeded is very small, compared to the issues it opens. However being able to switch to WS on any HTTP request seems rather important to save a few RTTs (and this one is OK). Regards, Willy From sm@elandsys.com Sun Mar 27 00:33:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4C53A69B3 for ; Sun, 27 Mar 2011 00:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCj9iDLrzjDq for ; Sun, 27 Mar 2011 00:33:46 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id DE3703A69B1 for ; Sun, 27 Mar 2011 00:33:45 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.215]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p2R7Z9GW029340 for ; Sun, 27 Mar 2011 00:35:15 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1301211316; bh=1XTfWC2cQAWHBGC6qExI+qisXWo=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type; b=rKvRJm+bZmpkLc/81O+ZD9uCo0cfucoBcXNl+kv8AnV5ptyIO1UUJwN4QotZM7CZE b5JKvFv75fggc3DML7WuZO9jNTo5KWVmfp87EphfbyoxOBFap9Mxc/YQJqhUoat/SE njdETpXW0h72rnwYG1wnQeS6Mw89MdAwfNuchhkM= Message-Id: <6.2.5.6.2.20110326231844.0d9d1078@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 26 Mar 2011 23:32:26 -0700 To: hybi@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [hybi] IETF 80 HYBI WG session X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 07:33:49 -0000 Hello, The IETF 80 HYBI WG session will held in the Congress Hall III room at 1:00 p.m. (CET) on Tuesday March 29, 2011. The agenda has been posted to http://tools.ietf.org/wg/hybi/agenda?item=agenda80.html The audio stream is at http://ietf80streaming.dnsalias.net/ietf/ietf804.m3u The Jabber room is xmpp:hybi@jabber.ietf.org Regards, S. Moonesamy HYBI WG Secretary From ibc@aliax.net Sun Mar 27 05:41:56 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2947328C13A for ; Sun, 27 Mar 2011 05:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHFYE8dg0Kql for ; Sun, 27 Mar 2011 05:41:55 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 3B6D228C112 for ; Sun, 27 Mar 2011 05:41:55 -0700 (PDT) Received: by qyk7 with SMTP id 7so1525137qyk.10 for ; Sun, 27 Mar 2011 05:43:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.122.81 with SMTP id k17mr2359707qcr.239.1301229811684; Sun, 27 Mar 2011 05:43:31 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Sun, 27 Mar 2011 05:43:31 -0700 (PDT) Date: Sun, 27 Mar 2011 14:43:31 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hybi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 12:41:56 -0000 Hi, draft-ietf-hybi-websocket-requirements-02 states that: ------------------------------------------ REQ. 9: The protocol SHOULD make it possible and practical to reuse existing HTTP components where appropriate. Reason: Reusing existing well-debugged software decreases the number of implementation errors as well as the possibility to introduce security holes, and increases development speed, especially when the WebSocket server is implemented as modules that plug in to existing popular Web servers. ------------------------------------------ However draft-ietf-hybi-thewebsocketprotocol-06 states: ----------------------------------------- The handshake from the server is much simpler than the client handshake. The first line is an HTTP Status-Line, with the status code 101: HTTP/1.1 101 Switching Protocols Any status code other than 101 MUST be treated as a failure if semantics of that status code are not defined in the context of a WebSocket connection, and the websocket connection aborted ----------------------------------------- So, could a websocket server reply 401 in order the WS client to resend the handshake request containing credentials? Could a websocket server reply a 3XX response to make a redirection? Could a websocket server reply 403 to indicate the client that it's not allowed for this service? Could the websocket server reply 404 in case the request URI doesn't exist in the server? It seems that the above text still relies on the old concept of "websocket looks like HTTP but it's not HTTP". IMHO this should be clarified in the draft. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From Martin.Thomson@commscope.com Sun Mar 27 05:45:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811C43A6823 for ; Sun, 27 Mar 2011 05:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaS7EPPT0pCT for ; Sun, 27 Mar 2011 05:45:41 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id C53403A681F for ; Sun, 27 Mar 2011 05:45:41 -0700 (PDT) X-AuditID: 0a0404e9-b7c0fae000001e9f-4f-4d8f31d590de Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id FD.DA.07839.5D13F8D4; Sun, 27 Mar 2011 07:47:17 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Sun, 27 Mar 2011 07:47:17 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sun, 27 Mar 2011 20:47:13 +0800 From: "Thomson, Martin" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Hybi Date: Sun, 27 Mar 2011 20:47:10 +0800 Thread-Topic: [hybi] Clarify wheter HTTP responses other than 101 are valid Thread-Index: AcvsfJggmFJ1LlpqQYiR5YlxwyvYawAAB1vQ Message-ID: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 12:45:42 -0000 T24gMjAxMS0wMy0yNyBhdCAxNDo0MzozMSwgScOxYWtpIEJheiBDYXN0aWxsbyB3cm90ZToNCj4g ICAgQW55IHN0YXR1cyBjb2RlIG90aGVyIHRoYW4gMTAxIE1VU1QgYmUgdHJlYXRlZCBhcyBhIGZh aWx1cmUgaWYNCj4gICAgc2VtYW50aWNzIG9mIHRoYXQgc3RhdHVzIGNvZGUgYXJlIG5vdCBkZWZp bmVkIGluIHRoZSBjb250ZXh0IG9mIGENCj4gICAgV2ViU29ja2V0IGNvbm5lY3Rpb24sIGFuZCB0 aGUgd2Vic29ja2V0IGNvbm5lY3Rpb24gYWJvcnRlZA0KPiANCj4gU28sIGNvdWxkIGEgd2Vic29j a2V0IHNlcnZlciByZXBseSA0MDEgaW4gb3JkZXIgdGhlIFdTIGNsaWVudCB0byANCj4gcmVzZW5k IHRoZSBoYW5kc2hha2UgcmVxdWVzdCBjb250YWluaW5nIGNyZWRlbnRpYWxzPw0KPiBDb3VsZCBh IHdlYnNvY2tldCBzZXJ2ZXIgcmVwbHkgYSAzWFggcmVzcG9uc2UgdG8gbWFrZSBhIHJlZGlyZWN0 aW9uPw0KPiBDb3VsZCBhIHdlYnNvY2tldCBzZXJ2ZXIgcmVwbHkgNDAzIHRvIGluZGljYXRlIHRo ZSBjbGllbnQgdGhhdCBpdCdzIA0KPiBub3QgYWxsb3dlZCBmb3IgdGhpcyBzZXJ2aWNlPw0KPiBD b3VsZCB0aGUgd2Vic29ja2V0IHNlcnZlciByZXBseSA0MDQgaW4gY2FzZSB0aGUgcmVxdWVzdCBV UkkgZG9lc24ndCANCj4gZXhpc3QgaW4gdGhlIHNlcnZlcj8NCg0KQWxsIG9mIHRoZXNlIGFyZSB1 bHRpbWF0ZWx5IGZhaWx1cmVzIHRvIGNvbXBsZXRlIHRoZSB1cGdyYWRlLg0KDQpDbGFyaWZpY2F0 aW9uIHdvdWxkIGJlIG5pY2UuDQoNCkkgYWxzbyBkb24ndCByZWFsbHkgZ2V0IHRoZSBxdWFsaWZp Y2F0aW9uOiAiaWYgc2VtYW50aWNzIG9mIHRoYXQgc3RhdHVzIGNvZGUgYXJlIG5vdCBkZWZpbmVk IGluIHRoZSBjb250ZXh0IG9mIGEgV2ViU29ja2V0IGNvbm5lY3Rpb24iLiAgU2VlbXMgbGlrZSBy ZWR1bmRhbnQgdG8gbWUuDQoNCg== From ibc@aliax.net Sun Mar 27 06:57:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0476C28C153 for ; Sun, 27 Mar 2011 06:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85e9yeyLh0F2 for ; Sun, 27 Mar 2011 06:57:47 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 52F2D28C150 for ; Sun, 27 Mar 2011 06:57:45 -0700 (PDT) Received: by qwg5 with SMTP id 5so1657537qwg.31 for ; Sun, 27 Mar 2011 06:59:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.63.154 with SMTP id b26mr1174925qci.163.1301234361731; Sun, 27 Mar 2011 06:59:21 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Sun, 27 Mar 2011 06:59:21 -0700 (PDT) Date: Sun, 27 Mar 2011 15:59:21 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hybi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [hybi] Typo in draft-06 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 13:57:48 -0000 draft-ietf-hybi-thewebsocketprotocol-06 in page 9 contains: ---------------------------------------------------------------------------= - The closing handshake is intended to replace the TCP closing handshake (FIN/ACK), on the basis that the TCP closing handshake is not always reliable end-to-end, especially in the presence of man-in- the-middle proxies and other intermediaries. By sending a close frame and waiting for a close frame in response, 1.5. Design philosophy ---------------------------------------------------------------------------= - Obvoiusly section 1.4 is not finished. --=20 I=C3=B1aki Baz Castillo From phil127@gmail.com Sun Mar 27 09:27:14 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D783A688A for ; Sun, 27 Mar 2011 09:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvlgHDif-5wD for ; Sun, 27 Mar 2011 09:27:12 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id EEB263A6882 for ; Sun, 27 Mar 2011 09:27:11 -0700 (PDT) Received: by wwa36 with SMTP id 36so2172208wwa.13 for ; Sun, 27 Mar 2011 09:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=BODLjvCMJka8/eW+gNIYzY+m3Nu23wnChhp/i4PsPtM=; b=Y3c6GZ89S1BUrvqwohgmacM/x3auu+eeFRMea2AdGpDODTEMvGFVmBodDParuEOAcY G+2vzYbqNGX1irfAE3sEX+u0Tn0zimVLgzJQekBBxodcYegpZhYsASqc+TCqiOpX+y0I ox4MrGKJg0hPBwgKP3qnD24kYgF/FGiPsaeXw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=TJTSqBaO1DBXrn5FSbJdXJiAQNdLL8/hQrSLJk45YDYSYL1qJ2M1eJAHwo9wCB1+se Ct+MM46FsaFT4vt4dgfcjasKiEgc0kYz2uxpOgKu3L/RNw9h1qquAyKL3I7m+42rTR/X lS7zodMZDL5U64lI/knxcdNfLJV+wOeN0maao= Received: by 10.227.0.88 with SMTP id 24mr3005012wba.123.1301243327269; Sun, 27 Mar 2011 09:28:47 -0700 (PDT) Received: from [212.201.79.65] (pptp-212-201-79-65.pptp.stw-bonn.de [212.201.79.65]) by mx.google.com with ESMTPS id y29sm1550147wbd.4.2011.03.27.09.28.45 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Mar 2011 09:28:46 -0700 (PDT) Message-ID: <4D8F6590.30808@gmail.com> Date: Sun, 27 Mar 2011 18:28:00 +0200 From: Philipp Serafin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Thomson, Martin" References: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Hybi Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 16:27:14 -0000 I believe there may be significant use-cases for 401 and 3xx responses, especially if WS endpoints would at one point be used as part of public web-apis. (Kind of like Rest-style apis are used today.) Like in HTTP-based apis, a provider could send 301 responses if an endpoint has changed or could use 307 responses for simple load-balancing. If this this doesn't pose too high of an implementation burden for clients, it might be useful to think about keeping those features. Regards, Philipp Serafin On 27.03.2011 14:47, Thomson, Martin wrote: > On 2011-03-27 at 14:43:31, Iñaki Baz Castillo wrote: >> Any status code other than 101 MUST be treated as a failure if >> semantics of that status code are not defined in the context of a >> WebSocket connection, and the websocket connection aborted >> >> So, could a websocket server reply 401 in order the WS client to >> resend the handshake request containing credentials? >> Could a websocket server reply a 3XX response to make a redirection? >> Could a websocket server reply 403 to indicate the client that it's >> not allowed for this service? >> Could the websocket server reply 404 in case the request URI doesn't >> exist in the server? > All of these are ultimately failures to complete the upgrade. > > Clarification would be nice. > > I also don't really get the qualification: "if semantics of that status code are not defined in the context of a WebSocket connection". Seems like redundant to me. > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From ibc@aliax.net Sun Mar 27 10:22:18 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56B43A68B8 for ; Sun, 27 Mar 2011 10:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoaPWRskB4xG for ; Sun, 27 Mar 2011 10:22:15 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 89FA63A67BD for ; Sun, 27 Mar 2011 10:22:15 -0700 (PDT) Received: by qyk7 with SMTP id 7so1606465qyk.10 for ; Sun, 27 Mar 2011 10:23:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.75.196 with SMTP id z4mr2507101qcj.277.1301246631926; Sun, 27 Mar 2011 10:23:51 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Sun, 27 Mar 2011 10:23:51 -0700 (PDT) Date: Sun, 27 Mar 2011 19:23:51 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hybi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 17:22:19 -0000 Hi, DNS SRV [*] is a mechanism for providing load-balancing and failover at client side. It's very common in modern communication protocols as SIP or XMPP. It's not used in HTTP, most probably because HTTP was created before SRV records, and when SRV was specified it was too late for including it into HTTP protocol. However WebSocket is a new protocol and could take advantage of it. For now, WebSocket draft just provide a host (hostname or IP) and port for the client to communicate with a WS server. Now that WS is still a draft it would be a good moment to include DNS SRV into WebSocket. Please consider it. Usage example: - A web page includes a WS connection to some-domain.org. - The web browser performs a DNS SRV query for _ws._tcp.some-domain.org and gets the following SRV records: _ws._tcp.some-domain.org. IN SRV 1 60 80 ws1.some-domain.org. _ws._tcp.some-domain.org. IN SRV 1 40 80 ws2.some-domain.org. _ws._tcp.some-domain.org. IN SRV 2 0 8080 ws3.some-domain.org. - The client would then choose between the two records with best priority (1) taking into account their weight (60 and 40), so for example ws1.some-domain.org:80. - In case such destination is unreachable the client would take the second one (ws2.some-domain.org:80). - If also unreachable, then the third option (with less priority) would be chosen (ws3.some-domain.org:8080). NOTE: In case of WS over SSL/TLS, the SRV query would be _wss._tcp.some-domain.org. In this way, WS gets load balancing (based on SRV records weitgh) and failover (based on SRV records priority). Of course, in case there is not SRV record for _ws._tcp.some-domain.org, the client would then perform a common DNS A query for some-domain.org as usual. So SRV records are not mandatory (this is also true in SIP and XMPP). IMHO, this is very useful and should be part of any new communication protocol in Internet. But it should be defined as part of the WebSocket specification from the beginning rather than being a future addition (after WS is widely implemented it will be hard to introduce it). Best regards. [*] DNS SRV: http://tools.ietf.org/html/rfc2782 --=20 I=C3=B1aki Baz Castillo From ietf@adambarth.com Sun Mar 27 13:08:10 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548F93A6940 for ; Sun, 27 Mar 2011 13:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.804 X-Spam-Level: X-Spam-Status: No, score=-2.804 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiaY2m2eMeHh for ; Sun, 27 Mar 2011 13:08:09 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 560A83A6929 for ; Sun, 27 Mar 2011 13:08:09 -0700 (PDT) Received: by qwg5 with SMTP id 5so1777816qwg.31 for ; Sun, 27 Mar 2011 13:09:45 -0700 (PDT) Received: by 10.229.37.2 with SMTP id v2mr2587725qcd.197.1301256585704; Sun, 27 Mar 2011 13:09:45 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by mx.google.com with ESMTPS id c27sm2192003qck.22.2011.03.27.13.09.44 (version=SSLv3 cipher=OTHER); Sun, 27 Mar 2011 13:09:44 -0700 (PDT) Received: by qyk29 with SMTP id 29so692187qyk.10 for ; Sun, 27 Mar 2011 13:09:44 -0700 (PDT) Received: by 10.224.140.6 with SMTP id g6mr2705597qau.14.1301256584067; Sun, 27 Mar 2011 13:09:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.89.83 with HTTP; Sun, 27 Mar 2011 13:09:13 -0700 (PDT) In-Reply-To: <4D8F6590.30808@gmail.com> References: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> <4D8F6590.30808@gmail.com> From: Adam Barth Date: Sun, 27 Mar 2011 13:09:13 -0700 Message-ID: To: Philipp Serafin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Thomson, Martin" , Hybi Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 20:08:10 -0000 Adding support for non-101 status codes has security consequences. In the interest of actually finishing the protocol, let's hold off on adding support for more use cases for this iteration of the protocol. Adam On Sun, Mar 27, 2011 at 9:28 AM, Philipp Serafin wrote: > I believe there may be significant use-cases for 401 and 3xx responses, > especially if WS endpoints would at one point be used as part of public > web-apis. (Kind of like Rest-style apis are used today.) > Like in HTTP-based apis, a provider could send 301 responses if an > endpoint has changed or could use 307 responses for simple > load-balancing. If this this doesn't pose too high of an implementation > burden for clients, it might be useful to think about keeping those > features. > > Regards, > Philipp Serafin > > On 27.03.2011 14:47, Thomson, Martin wrote: >> On 2011-03-27 at 14:43:31, I=F1aki Baz Castillo wrote: >>> =A0 =A0Any status code other than 101 MUST be treated as a failure if >>> =A0 =A0semantics of that status code are not defined in the context of = a >>> =A0 =A0WebSocket connection, and the websocket connection aborted >>> >>> So, could a websocket server reply 401 in order the WS client to >>> resend the handshake request containing credentials? >>> Could a websocket server reply a 3XX response to make a redirection? >>> Could a websocket server reply 403 to indicate the client that it's >>> not allowed for this service? >>> Could the websocket server reply 404 in case the request URI doesn't >>> exist in the server? >> All of these are ultimately failures to complete the upgrade. >> >> Clarification would be nice. >> >> I also don't really get the qualification: "if semantics of that status = code are not defined in the context of a WebSocket connection". =A0Seems li= ke redundant to me. >> >> _______________________________________________ >> 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 > From ibc@aliax.net Sun Mar 27 13:41:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7BBF28C132 for ; Sun, 27 Mar 2011 13:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UDgrSiIMr4E for ; Sun, 27 Mar 2011 13:41:26 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id EECDD28C12B for ; Sun, 27 Mar 2011 13:41:25 -0700 (PDT) Received: by qwg5 with SMTP id 5so1788652qwg.31 for ; Sun, 27 Mar 2011 13:43:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.122.81 with SMTP id k17mr2616639qcr.239.1301258582623; Sun, 27 Mar 2011 13:43:02 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Sun, 27 Mar 2011 13:43:02 -0700 (PDT) In-Reply-To: References: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> <4D8F6590.30808@gmail.com> Date: Sun, 27 Mar 2011 22:43:02 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Adam Barth Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Thomson, Martin" , Hybi Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 20:41:27 -0000 2011/3/27 Adam Barth : > Adding support for non-101 status codes has security consequences. Which ones? > In the interest of actually finishing the protocol, let's hold off on > adding support for more use cases for this iteration of the protocol. Then a requeriment in draft-ietf-hybi-websocket-requirements-02 is false: REQ. 9: The protocol SHOULD make it possible and practical to reuse existing HTTP components where appropriate. --=20 I=C3=B1aki Baz Castillo From ietf@adambarth.com Sun Mar 27 14:11:43 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7401D3A692E for ; Sun, 27 Mar 2011 14:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VvQtmp6zzWi for ; Sun, 27 Mar 2011 14:11:41 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id E7ACE28C112 for ; Sun, 27 Mar 2011 14:11:38 -0700 (PDT) Received: by vxg33 with SMTP id 33so2155959vxg.31 for ; Sun, 27 Mar 2011 14:13:15 -0700 (PDT) Received: by 10.52.172.2 with SMTP id ay2mr4479817vdc.50.1301260395508; Sun, 27 Mar 2011 14:13:15 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by mx.google.com with ESMTPS id g2sm1766158vbz.12.2011.03.27.14.13.11 (version=SSLv3 cipher=OTHER); Sun, 27 Mar 2011 14:13:15 -0700 (PDT) Received: by qwg5 with SMTP id 5so1798266qwg.31 for ; Sun, 27 Mar 2011 14:13:11 -0700 (PDT) Received: by 10.224.201.130 with SMTP id fa2mr2659891qab.364.1301260391163; Sun, 27 Mar 2011 14:13:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.89.83 with HTTP; Sun, 27 Mar 2011 14:12:40 -0700 (PDT) In-Reply-To: References: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> <4D8F6590.30808@gmail.com> From: Adam Barth Date: Sun, 27 Mar 2011 14:12:40 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Thomson, Martin" , Hybi Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 21:11:43 -0000 On Sun, Mar 27, 2011 at 1:43 PM, I=F1aki Baz Castillo wrote= : > 2011/3/27 Adam Barth : >> Adding support for non-101 status codes has security consequences. > > Which ones? Redirects, especially, but other ones as well (even 200). >> In the interest of actually finishing the protocol, let's hold off on >> adding support for more use cases for this iteration of the protocol. > > Then a requeriment in draft-ietf-hybi-websocket-requirements-02 is false: > > =A0REQ. 9: =A0The protocol SHOULD make it possible and practical to reuse > =A0 =A0 existing HTTP components where appropriate. The current draft already makes it possible and practical to reuse existing HTTP components where appropriate. Adam From ibc@aliax.net Sun Mar 27 14:16:47 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FCC28C157 for ; Sun, 27 Mar 2011 14:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCJZ+oQejYbn for ; Sun, 27 Mar 2011 14:16:46 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 6C06228C148 for ; Sun, 27 Mar 2011 14:16:46 -0700 (PDT) Received: by qwg5 with SMTP id 5so1799871qwg.31 for ; Sun, 27 Mar 2011 14:18:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.122.81 with SMTP id k17mr2637452qcr.239.1301260703039; Sun, 27 Mar 2011 14:18:23 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Sun, 27 Mar 2011 14:18:23 -0700 (PDT) In-Reply-To: References: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> <4D8F6590.30808@gmail.com> Date: Sun, 27 Mar 2011 23:18:23 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Adam Barth Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Thomson, Martin" , Hybi Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 21:16:47 -0000 2011/3/27 Adam Barth : > On Sun, Mar 27, 2011 at 1:43 PM, I=C3=B1aki Baz Castillo = wrote: >> 2011/3/27 Adam Barth : >>> Adding support for non-101 status codes has security consequences. >> >> Which ones? > > Redirects, especially, but other ones as well (even 200). If redirects are not a problem in "normal" HTTP, why should them be a security problem in WebSocket handshake? >>> In the interest of actually finishing the protocol, let's hold off on >>> adding support for more use cases for this iteration of the protocol. >> >> Then a requeriment in draft-ietf-hybi-websocket-requirements-02 is false= : >> >> =C2=A0REQ. 9: =C2=A0The protocol SHOULD make it possible and practical t= o reuse >> =C2=A0 =C2=A0 existing HTTP components where appropriate. > > The current draft already makes it possible and practical to reuse What do you mean with "possible and practical to reuse"? currently it's not defined what should happen if the client receives a response other than 101 during the handshake (well, it's specified that it should consider it an error). I don't think this can be called "HTTP reuse". --=20 I=C3=B1aki Baz Castillo From ietf@adambarth.com Sun Mar 27 14:31:07 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257F13A6969 for ; Sun, 27 Mar 2011 14:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUWKsPytwl8L for ; Sun, 27 Mar 2011 14:31:06 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 454343A6968 for ; Sun, 27 Mar 2011 14:31:06 -0700 (PDT) Received: by vxg33 with SMTP id 33so2162595vxg.31 for ; Sun, 27 Mar 2011 14:32:43 -0700 (PDT) Received: by 10.52.98.97 with SMTP id eh1mr4424065vdb.148.1301261562769; Sun, 27 Mar 2011 14:32:42 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by mx.google.com with ESMTPS id e37sm1772846vbm.17.2011.03.27.14.32.41 (version=SSLv3 cipher=OTHER); Sun, 27 Mar 2011 14:32:41 -0700 (PDT) Received: by qyk7 with SMTP id 7so1682820qyk.10 for ; Sun, 27 Mar 2011 14:32:41 -0700 (PDT) Received: by 10.224.140.6 with SMTP id g6mr2751086qau.14.1301261561064; Sun, 27 Mar 2011 14:32:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.89.83 with HTTP; Sun, 27 Mar 2011 14:32:11 -0700 (PDT) In-Reply-To: References: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> <4D8F6590.30808@gmail.com> From: Adam Barth Date: Sun, 27 Mar 2011 14:32:11 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Thomson, Martin" , Hybi Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 21:31:07 -0000 On Sun, Mar 27, 2011 at 2:18 PM, I=F1aki Baz Castillo wrote= : > 2011/3/27 Adam Barth : >> On Sun, Mar 27, 2011 at 1:43 PM, I=F1aki Baz Castillo wr= ote: >>> 2011/3/27 Adam Barth : >>>> Adding support for non-101 status codes has security consequences. >>> >>> Which ones? >> >> Redirects, especially, but other ones as well (even 200). > > If redirects are not a problem in "normal" HTTP, why should them be a > security problem in WebSocket handshake? I'm not really that interested in being drawn into this discussion at this time. Suffice it to saw that supporting non-101 status codes has security consequence and would require further analysis, delaying shipping the protocol significantly. I'd prefer to ship what we have and consider supporting more use cases in a future iteration of the protocol. Adam From ibc@aliax.net Sun Mar 27 14:44:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F0F628C157 for ; Sun, 27 Mar 2011 14:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jys0AyuV5AJT for ; Sun, 27 Mar 2011 14:44:23 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id A09BD28C0E0 for ; Sun, 27 Mar 2011 14:44:23 -0700 (PDT) Received: by qwg5 with SMTP id 5so1808519qwg.31 for ; Sun, 27 Mar 2011 14:46:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.169 with SMTP id t41mr2570919qch.201.1301262360268; Sun, 27 Mar 2011 14:46:00 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Sun, 27 Mar 2011 14:46:00 -0700 (PDT) In-Reply-To: References: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> <4D8F6590.30808@gmail.com> Date: Sun, 27 Mar 2011 23:46:00 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Adam Barth Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Thomson, Martin" , Hybi Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 21:44:24 -0000 2011/3/27 Adam Barth : > Suffice it to saw that supporting non-101 status codes has > security consequence and would require further analysis Then maybe you mean "supporting non-101 status codes COULD have security consequence..." :) --=20 I=C3=B1aki Baz Castillo From gregw@intalio.com Sun Mar 27 16:27:55 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5395E3A696E for ; Sun, 27 Mar 2011 16:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOdXxdzRXM42 for ; Sun, 27 Mar 2011 16:27:54 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id CFCD93A67AB for ; Sun, 27 Mar 2011 16:27:53 -0700 (PDT) Received: by vws12 with SMTP id 12so2194476vws.31 for ; Sun, 27 Mar 2011 16:29:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.4 with SMTP id 4mr1247687vda.104.1301268570187; Sun, 27 Mar 2011 16:29:30 -0700 (PDT) Received: by 10.52.155.71 with HTTP; Sun, 27 Mar 2011 16:29:30 -0700 (PDT) In-Reply-To: References: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> <4D8F6590.30808@gmail.com> Date: Mon, 28 Mar 2011 10:29:30 +1100 Message-ID: From: Greg Wilkins To: Adam Barth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Thomson, Martin" , Hybi Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 23:27:55 -0000 On 28 March 2011 07:09, Adam Barth wrote: > Adding support for non-101 status codes has security consequences. =A0In > the interest of actually finishing the protocol, let's hold off on > adding support for more use cases for this iteration of the protocol. Adam, I do agree we want to start another long discussion about security consequences of non-101 responses. However, I don't think that prohibition is the answer either. Firstly, I actually don't think we can prohibit non-101 responses. We have consensus that before the 101 the handshake must be HTTP compliant, and sending 400, 401, 301, 500, 503 are all HTTP compliant responses that will very likely be seen no matter what we say here. So I think the protocol must allow these responses as valid ways to fail the upgrade. However, it is a totally different matter to say if clients should respond to these codes (eg by following redirects or providing credentials). The protocol may allow redirects, but the browsers may decide for security or other reasons not to follow them. Obviously for portability, we want browsers to mostly act the same, but maybe that common behaviour should be decided by the HTML5 working groups rather than by the protocol spec. So we should make sure the text of the protocol spec makes it clear that non-101 response codes may be seen. The spec can also say that it is a decision of the particular client if any non-101 responses are acted on or ignored. cheers From gregw@intalio.com Sun Mar 27 16:37:44 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB863A6986 for ; Sun, 27 Mar 2011 16:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmsNnGawB0MU for ; Sun, 27 Mar 2011 16:37:43 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 623EA3A697E for ; Sun, 27 Mar 2011 16:37:43 -0700 (PDT) Received: by vxg33 with SMTP id 33so2203738vxg.31 for ; Sun, 27 Mar 2011 16:39:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.18.6 with SMTP id s6mr4637825vdd.144.1301269149282; Sun, 27 Mar 2011 16:39:09 -0700 (PDT) Received: by 10.52.155.71 with HTTP; Sun, 27 Mar 2011 16:39:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Mar 2011 10:39:09 +1100 Message-ID: From: Greg Wilkins To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 23:37:44 -0000 I agree it would be good to have websockets somehow support DNS loadbalancing. However, I do know that we have been very concerned to reduce the latency needed to establish a WS connection and I'd be concerned if every normal WS connection would now be delayed by an extra DNS lookup time. I'd also not like to make it mandatory that clients have to support it. Would it be practicable to only support this if the client used _ws._tcp.mydomain.org as the hostname in the WS connection? If they used www.mydomain.org, then normal DNS processing would take place? cheers From ibc@aliax.net Sun Mar 27 16:52:17 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5F728C173 for ; Sun, 27 Mar 2011 16:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkeDSZWzEuWg for ; Sun, 27 Mar 2011 16:52:16 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 23FF628C16E for ; Sun, 27 Mar 2011 16:52:15 -0700 (PDT) Received: by qwg5 with SMTP id 5so1844756qwg.31 for ; Sun, 27 Mar 2011 16:53:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.40.198 with SMTP id l6mr2822640qae.47.1301270032248; Sun, 27 Mar 2011 16:53:52 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Sun, 27 Mar 2011 16:53:52 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Mar 2011 01:53:52 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Greg Wilkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 23:52:17 -0000 2011/3/28 Greg Wilkins : > I agree it would be good to have websockets somehow support DNS loadbalan= cing. > > However, I do know that we have been very concerned to reduce the > latency needed to establish a WS connection and I'd be concerned if > every normal WS connection would now be delayed by an extra DNS lookup > time. SIP clients (phones usually) use NAPTR and SRV queries. XMPP clients use SRV queries. Both are realtime protocols, so the minimal latency an extra DNS query takes is negligible. Also, such DNS SRV query is *just* performed once: before establishing the connection with the WS server. > I'd also not like to make it mandatory that clients have to > support it. It's possible to create a SRV and a A record for a domain. Clients not implementing SRV could just query the A record. > Would it be practicable to only support this if the client used > _ws._tcp.mydomain.org as the hostname in the WS connection? =C2=A0If they > used www.mydomain.org, then normal DNS processing would take place? No, that it's not the way DNS SRV works. The client would just see "ws://mydomain.org/chat" in the JavaScript code got from the HTTP server. Since the WS URI doesn't not contain a port, then the client should perform a DNS SRV query with this data: - domain: mydomain.org - service: ws - transport: tcp Don't think that _ws._tcp.mydomain.org is a real domain (in fact the symbol "_" is invalid in a domain). It's just a representation of the query the client must perform: _SERVICE._TRANSPORT.DOMAIN. If the URI would include a port ("ws://mydomain.org:80/chat") then the client should NOT perform a SRV query, but just a A query. So, in case the URI has no port ("ws://mydomain.org/chat") the client should perform a SRV query for domain "mydomain.org", service "ws" and transport "tcp". If there is a SRV record for such query, then use it (it would require an aditional DNS A query for the chosen record entry). If there is no SRV record, then the client should perform a normal A query for domain "mydomain.org" and assume default port 80. As I said, SRV is widely used in SIP and XMPP, and it's very useful and eas= y. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Sun Mar 27 16:56:45 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D116228C173 for ; Sun, 27 Mar 2011 16:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQGb52CPVSVI for ; Sun, 27 Mar 2011 16:56:44 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 646EC28C16E for ; Sun, 27 Mar 2011 16:56:44 -0700 (PDT) Received: by qwg5 with SMTP id 5so1845884qwg.31 for ; Sun, 27 Mar 2011 16:58:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.122.81 with SMTP id k17mr2710359qcr.239.1301270301003; Sun, 27 Mar 2011 16:58:21 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Sun, 27 Mar 2011 16:58:20 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Mar 2011 01:58:20 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Greg Wilkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 23:56:46 -0000 2011/3/28 Greg Wilkins : > I agree it would be good to have websockets somehow support DNS loadbalan= cing. SRV is not just for load-balancing (with different weight per entry), but also for failover/redundancy. This is, if the chosen entry is unreachable, the client would use the next one. This is important. --=20 I=C3=B1aki Baz Castillo From Martin.Thomson@commscope.com Sun Mar 27 23:46:40 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D5E3A6869 for ; Sun, 27 Mar 2011 23:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azZCXg3KbdBk for ; Sun, 27 Mar 2011 23:46:39 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id B4F533A6866 for ; Sun, 27 Mar 2011 23:46:39 -0700 (PDT) X-AuditID: 0a0404e8-b7bd2ae0000014c1-15-4d902f305bae Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 65.AE.05313.03F209D4; Mon, 28 Mar 2011 01:48:16 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 28 Mar 2011 01:48:16 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 28 Mar 2011 14:48:13 +0800 From: "Thomson, Martin" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Hybi Date: Mon, 28 Mar 2011 14:48:11 +0800 Thread-Topic: [hybi] DNS SRV for WebSocket Thread-Index: Acvso8NTGcm30+v2TMagjtC1be2POQATUm0Q Message-ID: <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 06:46:40 -0000 T24gMjAxMS0wMy0yNyBhdCAxOToyMzo1MSwgScOxYWtpIEJheiBDYXN0aWxsbyB3cm90ZToNCj4g SGksIEROUyBTUlYgWypdIGlzIGEgbWVjaGFuaXNtIGZvciBwcm92aWRpbmcgbG9hZC1iYWxhbmNp bmcgYW5kIA0KPiBmYWlsb3ZlciBhdCBjbGllbnQgc2lkZS4gSXQncyB2ZXJ5IGNvbW1vbiBpbiBt b2Rlcm4gY29tbXVuaWNhdGlvbiANCj4gcHJvdG9jb2xzIGFzIFNJUCBvciBYTVBQLiBJdCdzIG5v dCB1c2VkIGluIEhUVFAsIG1vc3QgcHJvYmFibHkgYmVjYXVzZSANCj4gSFRUUCB3YXMgY3JlYXRl ZCBiZWZvcmUgU1JWIHJlY29yZHMsIGFuZCB3aGVuIFNSViB3YXMgc3BlY2lmaWVkIGl0IHdhcyAN Cj4gdG9vIGxhdGUgZm9yIGluY2x1ZGluZyBpdCBpbnRvIEhUVFAgcHJvdG9jb2wuIEhvd2V2ZXIg V2ViU29ja2V0IGlzIGEgDQo+IG5ldyBwcm90b2NvbCBhbmQgY291bGQgdGFrZSBhZHZhbnRhZ2Ug b2YgaXQuDQoNCkkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBuZWNlc3NhcnkuICBTUlYgZXhpc3RzIHRv IHByb3ZpZGUgbmFtZS1iYXNlZCBkaXNjb3ZlcnkgZm9yIGEgc2VydmljZSAod2l0aG91dCBhIGRl ZmF1bHQgcG9ydCkuICBUaGlzIGlzIGxhcmdlbHkgdW5uZWNlc3NhcnkgZm9yIFdlYlNvY2tldHMu ICBJbiBhY3R1YWxpdHksIGl0J3MgcHJvYmFibHkgbW9yZSBsaWtlbHkgdG8gaW50ZXJmZXJlLiAg SS5lLiwgd2hpY2ggcG9ydCBkbyB5b3UgdXNlOiB0aGUgb25lIGluIHRoZSBVUkksIG9yIHRoZSBv bmUgdGhhdCBTUlYgdG9sZCB5b3UgdG8gdXNlLg0KDQotLU1hcnRpbg0K From dave@cridland.net Mon Mar 28 00:54:32 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448623A6893 for ; Mon, 28 Mar 2011 00:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WRqb+IrbWVq for ; Mon, 28 Mar 2011 00:54:31 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 12C453A6867 for ; Mon, 28 Mar 2011 00:54:31 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 6A18F1168087; Mon, 28 Mar 2011 08:55:59 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojFz9sk2DmJL; Mon, 28 Mar 2011 08:55:39 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 6FFC61168067; Mon, 28 Mar 2011 08:55:37 +0100 (BST) References: <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com> MIME-Version: 1.0 Message-Id: <4126.1301298937.410511@puncture> Date: Mon, 28 Mar 2011 08:55:37 +0100 From: Dave Cridland To: "Thomson, Martin" , =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , Server-Initiated HTTP Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 07:54:32 -0000 On Mon Mar 28 07:48:11 2011, Thomson, Martin wrote: > On 2011-03-27 at 19:23:51, Iñaki Baz Castillo wrote: > > Hi, DNS SRV [*] is a mechanism for providing load-balancing and > > failover at client side. It's very common in modern communication > > protocols as SIP or XMPP. It's not used in HTTP, most probably > because > > HTTP was created before SRV records, and when SRV was specified > it was > > too late for including it into HTTP protocol. However WebSocket > is a > > new protocol and could take advantage of it. > > I don't think this is necessary. SRV exists to provide name-based > discovery for a service (without a default port). This is largely > unnecessary for WebSockets. In actuality, it's probably more > likely to interfere. I.e., which port do you use: the one in the > URI, or the one that SRV told you to use. I suggested the use of SRV myself some months ago. Stream based services benefit hugely from SRV records, and these have been deployed in the field with much success within the XMPP world. They are generally not used for port selection, but to allow the diversion of a service from one name (the domain) to another (the providing host). Use in WebSockets would allow a stock webserver to be used for static content whilst using a different specialist server (or servers) for WebSocket connections, which might prove very useful. (To clarify: in XMPP, they're used heavily, and nearly always use the same port numbers.) Specifying that if a port number is provided, then SRV lookup should not be performed, is I think sufficient to remove ambiguity. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From ibc@aliax.net Mon Mar 28 01:33:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 507D13A6893 for ; Mon, 28 Mar 2011 01:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62WVFvKQMKol for ; Mon, 28 Mar 2011 01:33:21 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 769F23A683C for ; Mon, 28 Mar 2011 01:33:21 -0700 (PDT) Received: by qwg5 with SMTP id 5so2028328qwg.31 for ; Mon, 28 Mar 2011 01:34:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.122.81 with SMTP id k17mr2984328qcr.239.1301301298544; Mon, 28 Mar 2011 01:34:58 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Mon, 28 Mar 2011 01:34:58 -0700 (PDT) In-Reply-To: <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com> Date: Mon, 28 Mar 2011 10:34:58 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Thomson, Martin" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 08:33:22 -0000 2011/3/28 Thomson, Martin : > I don't think this is necessary. =C2=A0SRV exists to provide name-based d= iscovery for a service (without a default port). =C2=A0This is largely unne= cessary for WebSockets. =C2=A0In actuality, it's probably more likely to in= terfere. =C2=A0I.e., which port do you use: the one in the URI, or the one = that SRV told you to use. Hi Martin, I think you haven't read my mails in which I explain how SRV works. I've clearly explained that, in case the URI contains a domain:port then no SRV query must be done, but just A. Also, I've explained that SRV is not just for "provide name-based discovery for a service". SRV provides *Real* load-balancing and failover. This doesn't exist in HTTP (in which just a hack is used: a DNS A record with different IP's). Please, reuse existing tecnologies. If you have more questions about SRV please ask me and I will describe in in more detail, but please, read first what I've already explained. Regards, --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Mar 28 01:39:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11FC3A684B for ; Mon, 28 Mar 2011 01:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3LQzQw+3jTr for ; Mon, 28 Mar 2011 01:39:27 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id ECF573A6830 for ; Mon, 28 Mar 2011 01:39:26 -0700 (PDT) Received: by qwg5 with SMTP id 5so2031910qwg.31 for ; Mon, 28 Mar 2011 01:41:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.179.203 with SMTP id br11mr3017181qab.197.1301301664109; Mon, 28 Mar 2011 01:41:04 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Mon, 28 Mar 2011 01:41:04 -0700 (PDT) In-Reply-To: <4126.1301298937.410511@puncture> References: <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com> <4126.1301298937.410511@puncture> Date: Mon, 28 Mar 2011 10:41:04 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Dave Cridland Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Thomson, Martin" , Server-Initiated HTTP Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 08:39:28 -0000 2011/3/28 Dave Cridland : > I suggested the use of SRV myself some months ago. > > Stream based services benefit hugely from SRV records, and these have bee= n > deployed in the field with much success within the XMPP world. Also in SIP world :) > They are generally not used for port selection, but to allow the diversio= n > of a service from one name (the domain) to another (the providing host). = Use > in WebSockets would allow a stock webserver to be used for static content > whilst using a different specialist server (or servers) for WebSocket > connections, which might prove very useful. > > (To clarify: in XMPP, they're used heavily, and nearly always use the sam= e > port numbers.) > > Specifying that if a port number is provided, then SRV lookup should not = be > performed, is I think sufficient to remove ambiguity. Yes it is. The problem is that IMHO people too much involved in HTTP doesn't know SRV as HTTP doesn't make usage of it. Also note that WebSocket takes no advantages of other existing tecnlogies. At the beginning it wasn't real HTTP, now it looks more like HTTP, but it takes no advantage of other cool specifications, why? Please guys, consider adding SRV to WebSocket, it's a great mechanism for providing load-balancing and failover without dirty hacks. This is the moment for it, and not later in an ugly feature addition nobody will support. --=20 I=C3=B1aki Baz Castillo From theturtle32@gmail.com Mon Mar 28 02:20:06 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632983A688F for ; Mon, 28 Mar 2011 02:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf4MZak1ZNjF for ; Mon, 28 Mar 2011 02:20:04 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id D11403A690B for ; Mon, 28 Mar 2011 02:20:04 -0700 (PDT) Received: by iye19 with SMTP id 19so3295204iye.31 for ; Mon, 28 Mar 2011 02:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=f7yFAI8WoVrEm8ay/RiLiFeYTm/bNixZGtp4sjkSaLI=; b=XLV6pVpEHuJA4Cgvex+EUsoePj9StmzIPpuL4TxCdI3Xjp21XRuZKWj31z0SxXPLnN mr7Pn3dO4SfKDsJri4Fg2SswHXb8YOxAl2yOLXtaZ55UY8S5nOYqdoza9AF19+RFuYNV C606mUfPSGIVrK2Bc1xfwFwS4NmPxs40VMeHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Pi1HBxiX7/rg35cVQB4o2iN6cukrsokpHJSu0srBmpL0sn+8+6Y9n7YY9RSt6FYQdM P4QcxxUfdCTeDECEnKboGkwBGxt4C0ycwr6RqNXG2Wix4h9zBnFVhosnP4Mw7YlStgto LDwpE/A+v1wGpzBT+SK0g1lNmYmoLK2hKRxtA= MIME-Version: 1.0 Received: by 10.231.67.201 with SMTP id s9mr3829155ibi.176.1301304101046; Mon, 28 Mar 2011 02:21:41 -0700 (PDT) Received: by 10.231.168.202 with HTTP; Mon, 28 Mar 2011 02:21:41 -0700 (PDT) Date: Mon, 28 Mar 2011 02:21:41 -0700 Message-ID: From: Brian To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [hybi] AS3 WebSocket -06 Library and Test App X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 09:20:06 -0000 My in-progress ActionScript 3 WebSocket-06 client library is now up on GitHub, in case any of you might find it a helpful sparring-partner for your server implementations. You can find it here: https://github.com/worlize/AS3WebSocket There are still a few things missing that I intend to address soon, and it hasn't undergone extensive testing yet. I also built a test application with Adobe Air that knows about a couple of the libwebsocket-test-server subprotocols. You can grab a pre-built .air binary of that app under the "Downloads" section of the GitHub repo. Screenshot showing AS3WebSocket interoperating with Andy Green's test page: http://blog.worlize.com/media/as3websocket.png Current Features: - Support for the -06 including the handshake, framing, and masking - Support for the deflate-stream extension Known Issues: - Fragmentation is not yet supported - There is no user-provided extension API implemented - No wss:// support yet - Only the libwebsocket-test-server subprotocols mentioned have been tested so far - Only tested in Adobe Air, not yet in Flash Player.. probably have to add a little code to make it check for a policy file for Flash Player. Cheers, Brian On Wed, Mar 9, 2011 at 1:38 PM, Brian wrote: > I just wanted to send a general "Thank you!" to everyone on the list > for all your long-suffering hard work that has made WebSockets a great > and yet still simple protocol. =A0Last night I coded up a partial client > implementation in Flash of the -06 draft... just enough to connect to > Andy Green's excellent libwebsockets-test-server using the > dumb-increment-protocol and receive the continually incrementing > numbers that it spits out. =A0I wrote an implementation of the handshake > and a parser for the framing based on nothing but the current -06 > draft, and to my surprise and delight, the whole thing worked > perfectly on the first try. =A0That is truly a testament to the quality > of the draft and the clarity of its writing, as well as the simplicity > of the protocol. =A0It's extremely close to that perfect balance point > of features vs. simplicity. > > So give yourselves all a collective pat on the back! =A0We've really got > an amazing working draft and an excellent protocol that is poised to > truly transform the real-time web once it's complete! =A0Actually > sitting down to write my own implementation has really re-kindled my > excitement and enthusiasm for the whole project! > > I plan to finish out the client implementation, with masking and > support for extensions very soon. =A0When it's in a more sane state I > will publish it on GitHub, along with a pre-compiled Adobe Air test > app that will work with all of Andy's libwebsockets-test-server > subprotocols. > > Cheers, > Brian > From Martin.Thomson@commscope.com Mon Mar 28 03:35:05 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E551A3A68F3 for ; Mon, 28 Mar 2011 03:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7ZeZUk6VaJi for ; Mon, 28 Mar 2011 03:35:03 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id B72FD3A6920 for ; Mon, 28 Mar 2011 03:35:03 -0700 (PDT) X-AuditID: 0a0404e9-b7c0fae000001e9f-e5-4d9064b896eb Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id F8.8A.07839.8B4609D4; Mon, 28 Mar 2011 05:36:40 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 28 Mar 2011 05:36:40 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 28 Mar 2011 18:36:36 +0800 From: "Thomson, Martin" To: Dave Cridland , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Server-Initiated HTTP Date: Mon, 28 Mar 2011 18:36:32 +0800 Thread-Topic: [hybi] DNS SRV for WebSocket Thread-Index: AcvtHZatVGXjcaAAQbu2Aze1/hzstQAFkv6g Message-ID: <8B0A9FCBB9832F43971E38010638454F04027B92DD@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com> <4126.1301298937.410511@puncture> In-Reply-To: <4126.1301298937.410511@puncture> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 10:35:05 -0000 On 2011-03-28 at 09:55:37, Dave Cridland wrote: > They are generally not used for port selection, but to allow the=20 > diversion of a service from one name (the domain) to another (the=20 > providing host).=20 Security on that front is a little iffy. See draft-barnes-hard-problem. From ibc@aliax.net Mon Mar 28 03:41:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D923A6910 for ; Mon, 28 Mar 2011 03:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcF75k2hg9ks for ; Mon, 28 Mar 2011 03:41:35 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 234C93A68F9 for ; Mon, 28 Mar 2011 03:41:35 -0700 (PDT) Received: by qwg5 with SMTP id 5so2106025qwg.31 for ; Mon, 28 Mar 2011 03:43:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.169 with SMTP id t41mr3012738qch.201.1301308992293; Mon, 28 Mar 2011 03:43:12 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Mon, 28 Mar 2011 03:43:12 -0700 (PDT) In-Reply-To: <8B0A9FCBB9832F43971E38010638454F04027B92DD@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com> <4126.1301298937.410511@puncture> <8B0A9FCBB9832F43971E38010638454F04027B92DD@SISPE7MB1.commscope.com> Date: Mon, 28 Mar 2011 12:43:12 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Thomson, Martin" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Server-Initiated HTTP Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 10:41:36 -0000 2011/3/28 Thomson, Martin : > On 2011-03-28 at 09:55:37, Dave Cridland wrote: >> They are generally not used for port selection, but to allow the >> diversion of a service from one name (the domain) to another (the >> providing host). > > Security on that front is a little iffy. =C2=A0See draft-barnes-hard-prob= lem. Do you consider this "security issue" a real show-stopper for supporting SRV records in WebSocket? Me not. The provider could use subdomains of its root domain as A records into its SRV record, so the problem doesn't arise. I don't think the corner case described in draft-barnes-hard-problem is so important. IMHO it's more important to provide load-balancing and failover to a new protocol. --=20 I=C3=B1aki Baz Castillo From Martin.Thomson@commscope.com Mon Mar 28 03:46:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC4B3A6A5A for ; Mon, 28 Mar 2011 03:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEUB8zINON7J for ; Mon, 28 Mar 2011 03:46:13 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 172253A6A31 for ; Mon, 28 Mar 2011 03:46:11 -0700 (PDT) X-AuditID: 0a0404e8-b7bd2ae0000014c1-97-4d9067550bb0 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 05.44.05313.557609D4; Mon, 28 Mar 2011 05:47:49 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 28 Mar 2011 05:47:49 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 28 Mar 2011 18:47:46 +0800 From: "Thomson, Martin" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Mon, 28 Mar 2011 18:47:44 +0800 Thread-Topic: [hybi] DNS SRV for WebSocket Thread-Index: AcvtNPH5orlvoNLgQ7euvx2Rg8fz4QAAA9Ww Message-ID: <8B0A9FCBB9832F43971E38010638454F04027B92DE@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com> <4126.1301298937.410511@puncture> <8B0A9FCBB9832F43971E38010638454F04027B92DD@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Server-Initiated HTTP Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 10:46:13 -0000 T24gMjAxMS0wMy0yOCBhdCAxMjo0MzoxMiwgScOxYWtpIEJheiBDYXN0aWxsbyB3cm90ZToNCj4g MjAxMS8zLzI4IFRob21zb24sIE1hcnRpbiA8TWFydGluLlRob21zb25AY29tbXNjb3BlLmNvbT46 DQo+ID4gT24gMjAxMS0wMy0yOCBhdCAwOTo1NTozNywgRGF2ZSBDcmlkbGFuZCB3cm90ZToNCj4g Pj4gVGhleSBhcmUgZ2VuZXJhbGx5IG5vdCB1c2VkIGZvciBwb3J0IHNlbGVjdGlvbiwgYnV0IHRv IGFsbG93IHRoZSANCj4gPj4gZGl2ZXJzaW9uIG9mIGEgc2VydmljZSBmcm9tIG9uZSBuYW1lICh0 aGUgZG9tYWluKSB0byBhbm90aGVyICh0aGUgDQo+ID4+IHByb3ZpZGluZyBob3N0KS4NCj4gPg0K PiA+IFNlY3VyaXR5IG9uIHRoYXQgZnJvbnQgaXMgYSBsaXR0bGUgaWZmeS4gwqBTZWUgZHJhZnQt YmFybmVzLWhhcmQtDQo+IHByb2JsZW0uDQo+IA0KPiBEbyB5b3UgY29uc2lkZXIgdGhpcyAic2Vj dXJpdHkgaXNzdWUiIGEgcmVhbCBzaG93LXN0b3BwZXIgZm9yIA0KPiBzdXBwb3J0aW5nIFNSViBy ZWNvcmRzIGluIFdlYlNvY2tldD8gTWUgbm90Lg0KDQpJdCB3YXNuJ3QgaW50ZW5kZWQgYXMgYW4g YXJndW1lbnQgYWxvbmcgdGhvc2UgbGluZXMuICBJIHdhcyBtZXJlbHkgaG9waW5nIHRvIGlsbHVt aW5hdGUgdGhlIGlzc3VlLg0KIA0KPiBUaGUgcHJvdmlkZXIgY291bGQgdXNlIHN1YmRvbWFpbnMg b2YgaXRzIHJvb3QgZG9tYWluIGFzIEEgcmVjb3JkcyBpbnRvIA0KPiBpdHMgU1JWIHJlY29yZCwg c28gdGhlIHByb2JsZW0gZG9lc24ndCBhcmlzZS4NCg0KSSdtIGFmcmFpZCB0aGF0IHRoaXMgZG9l c24ndCB3b3JrLiAgVGhlIG5hdHVyZSBvZiBETlMgZGVsZWdhdGlvbnMgYXJlIHN1Y2ggdGhhdCBz dWJkb21haW5zIGNhbm5vdCBiZSBndWFyYW50ZWVkIHRvIGJlbG9uZyB0byB0aGUgc2FtZSBlbnRp dHkuDQoNCj4gSSBkb24ndCB0aGluayB0aGUgY29ybmVyIGNhc2UgZGVzY3JpYmVkIGluIGRyYWZ0 LWJhcm5lcy1oYXJkLXByb2JsZW0gDQo+IGlzIHNvIGltcG9ydGFudC4gSU1ITyBpdCdzIG1vcmUg aW1wb3J0YW50IHRvIHByb3ZpZGUgbG9hZC1iYWxhbmNpbmcgDQo+IGFuZCBmYWlsb3ZlciB0byBh IG5ldyBwcm90b2NvbC4NCg0KSXQncyBub3QgYSBjb3JuZXIgY2FzZS4gIEl0J3MgdGhlIGdlbmVy YWwgY2FzZSBvZiBoYXZpbmcgYSBzZWN1cmUgZGVsZWdhdGlvbi4gIERlbGVnYXRpb24gY2FuIGJl IGRvbmUgcmVhbGx5IGVhc2lseSB3aXRob3V0IGFueSBhc3N1cmFuY2Ugb2YgaW50ZWdyaXR5LCBi dXQgaWYgeW91IHdhbnQgYSBzZWN1cmUgZGVsZWdhdGlvbiwgdGhhdCdzIG5vdCBlYXN5IChpdCdz IEhBUkQpLg0KDQotLU1hcnRpbg0KDQo= From dave@cridland.net Mon Mar 28 03:55:30 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DC5F3A63C9 for ; Mon, 28 Mar 2011 03:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBYc8jrQ2Wpw for ; Mon, 28 Mar 2011 03:55:29 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 473523A635F for ; Mon, 28 Mar 2011 03:55:29 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 6C01F116808F; Mon, 28 Mar 2011 11:57:05 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0YYxqekDgeE; Mon, 28 Mar 2011 11:57:03 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 7519C1168067; Mon, 28 Mar 2011 11:57:03 +0100 (BST) References: <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com> <4126.1301298937.410511@puncture> <8B0A9FCBB9832F43971E38010638454F04027B92DD@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F04027B92DD@SISPE7MB1.commscope.com> MIME-Version: 1.0 Message-Id: <4126.1301309823.420847@puncture> Date: Mon, 28 Mar 2011 11:57:03 +0100 From: Dave Cridland To: "Thomson\, Martin" , =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , Server-Initiated HTTP Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 10:55:30 -0000 On Mon Mar 28 11:36:32 2011, Thomson, Martin wrote: > On 2011-03-28 at 09:55:37, Dave Cridland wrote: > > They are generally not used for port selection, but to allow the > > diversion of a service from one name (the domain) to another (the > > providing host). > > Security on that front is a little iffy. See > draft-barnes-hard-problem. Actually it's straightforward from a technical standpoint, until you delegate services across administrative boundaries. Again, the XMPP world has been successfully authenticating using X.509 certificates with SRV records in play for many years. Richard's been working closely with the XMPP community to find a solution to the "HARD" problem of cross-boundary delegation, but meanwhile I'd note that the problem exists with HTTP just as much as with XMPP and other SRV-using protocols, the primary distinction being that there is no explicit delegation visible, so people don't notice it as much. (Which is odd, since in HTTP there is a far *higher* delegation level for secure sites, as few as there are). The actual problem only exists in the case where the private key cannot be given to the hosting organization, and I'd note is easier to solve if SRV records exist, thanks to DNSSEC (and the ability to then validate the delegation to an intermediate indentity one can use in the certificate). So in summary, SRV records actually simplify the problem. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From alexey.melnikov@isode.com Mon Mar 28 05:18:05 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 528663A6452 for ; Mon, 28 Mar 2011 05:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.175 X-Spam-Level: X-Spam-Status: No, score=-102.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+Izl9CQvhY7 for ; Mon, 28 Mar 2011 05:18:03 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id DCDFA3A6817 for ; Mon, 28 Mar 2011 05:18:02 -0700 (PDT) Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 28 Mar 2011 13:19:39 +0100 Message-ID: <4D907CC6.7080707@isode.com> Date: Mon, 28 Mar 2011 14:19:18 +0200 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: hybi@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [hybi] Review of draft-ietf-hybi-thewebsocketprotocol-06.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:18:05 -0000 Hi, I've performed a detailed Area Director-style review of the document, which is described below. More of the changes listed below are nits or IETF-specific changes (e.g. IANA registration) that need to be done before this document is submitted for IESG review. 1.2. Protocol overview Data is sent on the wire in the form of frames that have an associated type. Broadly speaking, there are types for textual data, which is interpreted as UTF-8 text, binary data (whose interpretation First reference to UTF-8 needs a reference. is left up to the application), and control frames, which are not intended to carry data for the application, but instead for protocol- level signaling, such as to signal that the connection should be closed. This version of the protocol defines six frame types and leaves ten reserved for future use. Some text explaining that a message consist of one or more frames is missing in this section. In Section 1.3: Additional headers are used to select options in the WebSocket protocol. Options available in this version are the subprotocol selector, |Sec-WebSocket-Protocol|, and |Cookie|, which can used for sending cookies to the server (e.g. as an authentication mechanism). The |Sec-WebSocket-Protocol| request-header field can be used to indicate what subprotocols (application-level protocols layered over the WebSocket protocol) are acceptable to the client. The server selects one of the acceptable protocols and echoes that value in its handshake to indicate that it has selected that protocol. Sec-WebSocket-Protocol: chat Why is Sec-WebSocket-Protocol an "option"? Can anything useful be done without it? If yes, this needs additional explanation. If not, this needs rephrasing. [...] To prove that the handshake was received, the server has to take two pieces of information and combine them to form a response. The first piece of information comes from the |Sec-WebSocket-Key| header in the client handshake: Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== For this header, the server has to take the value (as present in the header, e.g. the base64-encoded version), base64 needs a reference. I think this needs to be clarified a bit: are leading and traling whitespaces removed from the value? and concatenate this with the GUID "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" in string form, which is unlikely to be used by network endpoints that do not understand the WebSocket protocol. A SHA-1 hash, base64-encoded, of this concatenation is then returned in the server's handshake [FIPS.180-2.2002]. The handshake from the server is much simpler than the client handshake. The first line is an HTTP Status-Line, with the status code 101: HTTP/1.1 101 Switching Protocols Any status code other than 101 MUST be treated as a failure if semantics of that status code are not defined in the context of a WebSocket connection, What does "if semantics of that status code are not defined in the context of a WebSocket connection" mean? and the websocket connection aborted. The headers follow the status code. Option fields can also be included. In this version of the protocol, the main option field is |Sec-WebSocket-Protocol|, which indicates the subprotocol that the server has selected. Web browsers verify that the server included one of the values as was specified in the |WebSocket| constructor. A server that speaks multiple subprotocols has to make sure it selects one based on the client's handshake and specifies it in its handshake. As above - why is this an option? The server can also set cookie-related option fields to _set_ cookies, as in HTTP. This needs a reference to the Cookie draft. In Section 1.4: By sending a close frame and waiting for a close frame in response, Unfinished sentence. In Section 1.6: This protocol is intended to fail to establish a connection with servers of pre-existing protocols like SMTP or HTTP, while allowing An Informative reference for SMTP is needed. HTTP servers to opt-in to supporting this protocol if desired. This is achieved by having a strict and elaborate handshake, and by limiting the data that can be inserted into the connection before the handshake is finished (thus limiting how much the server can be influenced). 1.7. Relationship to TCP and HTTP Based on the expert recommendation of the IANA, the WebSocket protocol by default uses port 80 for regular WebSocket connections and port 443 for WebSocket connections tunneled over TLS. A reference to TLS is needed here. 1.9. Subprotocols using the WebSocket protocol _This section is non-normative._ The client can request that the server use a specific subprotocol by including the |Sec-WebSocket-Protocol| field in its handshake. If it is specified, the server needs to include the same field and one of the selected subprotocol values in its response for the connection to be established. These subprotocol names do not need to be registered, but if a I question the wisdom of not having standard subprotocols registered. Defining an IANA registry with a liberal registration policy (e.g. "First Come First Served") is easy. 2.1. Terminology The term "URI" is used in this section in a manner consistent with the terminology used in HTML, namely, to denote a string that might or might not be a valid URI or IRI and to which certain error handling behaviors will be applied when the string is parsed. [RFC3986] I don't think this is very useful. I think for the purposes used in this document, only valid URI are in scope. 3.1. Parsing WebSocket URIs The steps to *parse a WebSocket URI's components* from a string /uri/ are as follows. These steps return either a /host/, a /port/, a /resource name/, and a /secure/ flag, or they fail. 1. If the /uri/ string is not an absolute URI, then fail this Did you mean URI or IRI here? [RFC3987] defines IRIs, is it needed? algorithm. [RFC3986] [RFC3987] 2. Resolve the /uri/ string using the resolve a Web address algorithm defined by the Web addresses specification, with the I think this is underspecified. URI character encoding set to UTF-8. [RFC3629] [RFC3986] [RFC3987] 3.3. Valid WebSocket URIs For a WebSocket URI to be considered valid, the following conditions MUST hold. o The /host/ must be ASCII-only (i.e. it must have been punycode- encoded This needs an Informative reference to punycode already if necessary, and MUST NOT contain any characters above U+007E). 4.1. Overview The base framing protocol defines a frame type with an opcode, a payload length, and designated locations for extension and application data, which together define the _payload_ data. Certain bits and opcodes are reserved for future expansion of the protocol. As such, In the absence of extensions negotiated during the opening handshake (Section 5), all reserved bits MUST be 0 and reserved opcode values MUST NOT be used. I think this needs to talk separately about what can be sent by compliant senders and what must be done by receivers if they see a non 0 reserved bit or an unrecognized opcode. The trac ticket about error handling is pretty much talking about the same thing (and mentions more). 4.3. Base Framing Protocol This wire format for the data transfer part is described by the ABNF I think the reference to [RFC5234] should go after "ABNF" and not at the end of this paragraph. Otherwise this is confusing. given in detail in this section. A high level overview of the framing is given in the following figure. [RFC5234] Extension data: n bytes The extension data is 0 bytes unless there is a reserved op-code or reserved bit present in the frame which indicates an extension has been negotiated. Any extension MUST specify the length of the extension data, or how that length may be calculated, and its use "its" refers to extension, not to the length, right? I suggest clarifying that. MUST be negotiated during the handshake. If present, the extension data is included in the total payload length. 4.5.1. Close Following the 2-byte integer the body MAY contain UTF-8 encoded data, the interpretation of which is not defined by this specification. Is this data human readable? If yes, please say so. If it is human readable, you need to be able to include optional language tags as per BCP 18. See for more details on how this can be addressed. 4.5.2. Ping The Ping message contains an opcode of 0x02. Upon receipt of a Ping message, an endpoint MUST send a Pong message in response. It SHOULD do so as soon as is practical. The message bodies of the Ping and Pong MUST be the same. I think this needs to clarify that a ping message doesn't contain any Extension data and that "message bodies" is the Application data. In Section 5.1: 2. If the user agent already has a WebSocket connection to the remote host (IP address) identified by /host/, even if known by It is not enough to use only the IP address to identify a WebSocket connection. The port number must also be used. Due to NATs/firewalls there is no guaranty that a connection to the same IP address and a different port will even be served by the same machine. another name, the user agent MUST wait until that connection has been established or for that connection to have failed. There MUST be no more than one connection in a CONNECTING state. If multiple connections to the same IP address are attempted simultaneously, the user agent MUST serialize them so that there is no more than one connection at a time running through the following steps. 3. _Proxy Usage_: If the user agent is configured to use a proxy when using the WebSocket protocol to connect to host /host/ and/or port /port/, then the user agent SHOULD connect to that Why SHOULD and not a MUST? I.e., what are [possible] reasons for violating the SHOULD? proxy and ask it to open a TCP connection to the host given by /host/ and the port given by /port/. If the user agent is not configured to use a proxy, then a direct TCP connection SHOULD be opened to the host given by /host/ and the port given by /port/. As above. NOTE: Implementations that do not expose explicit UI for selecting a proxy for WebSocket connections separate from other proxies are encouraged to use a SOCKS proxy for WebSocket SOCKS needs an Informative reference. connections, if available, or failing that, to prefer the proxy configured for HTTPS connections over the proxy configured for HTTP connections. 5. If /secure/ is true, the user agent MUST perform a TLS handshake over the connection. If this fails (e.g. the server's certificate could not be verified), This also need a Normative reference to RFC 2818, section 3.1, because TLS server certificate verification procedures are protocol specific. then the user agent MUST fail the WebSocket connection and abort the connection. Otherwise, all further communication on this channel MUST run through the encrypted tunnel. [RFC2246] 7. The request MUST include a header with the name "Sec-WebSocket- Key". The value of this header MUST be a nonce consisting of a randomly selected 16-byte value that has been base64-encoded [RFC3548]. The nonce MUST be randomly selected randomly for Delete one of the two "randomly". each connection. 10. The request MAY include a header with the name "Sec-WebSocket- What is the semantics of the request if it doesn't contain this header field? Protocol". If present, this value indicates the subprotocol(s) the client wishes to speak. The elements that comprise this value MUST be non-empty strings with characters in the range U+0021 to U+007E and MUST all be unique. The ABNF for the value of this header is 1#(token | quoted-string), where the definitions of constructs and rules are as given in [RFC2616]. 5.2.1. Reading the client's opening handshake The client handshake consists of the following parts. If the server, while reading the handshake, finds that the client did not send a handshake that matches the description below, the server must abort s/must/MUST the WebSocket connection. 5.2.1. Reading the client's opening handshake 6. Optionally, a "Sec-WebSocket-Protocol header, with a list of values indicating which protocols the client would like to speak, ordered by preference. What is the semantics of the request if it doesn't contain this header field? 5.2.2. Sending the server's opening handshake 2. Establish the following information: [...] /version/ The |Sec-WebSocket-Version| header in the client's handshake includes the version of the WebSocket protocol the client is attempting to communicate with. If this version does not match a version understood by the server, the server MUST abort the WebSocket connection. The server MAY send a non-200 response code with a |Sec-WebSocket-Version| header indicating the version(s) the server is capable of understanding along with this non-200 response code. I think "along with this non-200 response code" can be deleted. 3. ... 3. Optionally, a "Sec-WebSocket-Protocol" header, with a value /subprotocol/ as defined in Paragraph 2 of Section 5.2.2. As mentioned above: why is this optional? 6.2. Handling errors in UTF-8 from the client When a server is to interpret a byte stream as UTF-8 but finds that the byte stream is not in fact a valid UTF-8 stream, behavior is undefined. A server could close the connection, convert invalid byte sequences to U+FFFD REPLACEMENT CHARACTERs, store the data verbatim, The latter is a security issue (e.g. can lead to buffer overflows when naive UTF-8 parsers are used), so it should be mentioned in the Security Considerations section. or perform application-specific processing. Subprotocols layered on the WebSocket protocol might define specific behavior for servers. 7.1.1. Close the WebSocket Connection To _Close the WebSocket Connection_, an endpoint closes the underlying TCP connection. An endpoint SHOULD use a method that cleanly closes the TCP connection, Actually the TLS session should also be closed cleanly, if possible/applicable. discarding any trailing bytes that may be received. And endpoint MAY close the connection via any means available when necessary, such as when under attack. 7.4. Status codes When closing an established connection (e.g. when sending a Close frame, after the handshake has completed), an endpoint MAY indicate a reason for closure. The interpretation of this reason by an endpoint, and the action an endpoint should take given this reason, are left undefined by this specification. This specification defines a set of pre-defined status codes, I think an IANA registry for these would be needed. and specifies which ranges may be used by extensions, frameworks, and end applications. 8.1. Negotiating extensions A client requests extensions by including a "Sec-WebSocket- Extensions" header, which follows the normal rules for HTTP headers (see [RFC2616] section 4.2) and the value of the header is defined by the following ABNF: extension-list = 1#extension extension = extension-token *( ";" extension-param ) extension-token = registered-token | private-use-token registered-token = token private-use-token = "x-" token extension-param = token [ "=" ( token | quoted-string ) ] Here you are using RFC 2616 ABNF and not RFC 5234 ABNF. You need to make this clear, because there are differences (e.g. implied LWS) Any extension-token used must either be a registered token (registration TBD), Yes, these need to be registered with IANA. or have a prefix of "x-" to indicate a private- use token. 8.2.1. Compression Senders using this extension MUST apply RFC 1951 encodings to all bytes of the data stream following the handshake including both data and control messages. The data stream MAY include multiple blocks of both compressed and uncompressed types as defined by RFC 1951. [RFC1951] Does this apply before or after masking? 9. Security considerations Servers that are not intended to process input from any Web page but only for certain sites should verify the "Origin" field is an origin they expect, and should only respond with the corresponding "Sec- WebSocket-Origin" if it is an accepted origin. Servers that only accept input from one origin can just send back that value in the "Sec-WebSocket-Origin" field, without bothering to check the client's value. Is "without bothering to check the client's value" part actually correct? 10.1. Registration of ws: scheme URI scheme syntax. In ABNF terms using the terminals from the URI specifications: [RFC5234] [RFC3986] "ws" ":" hier-part [ "?" query ] The path and query components form the resource name sent to the server to identify the kind of service desired. Other components have the meanings described in RFC3986. Which "other components"? I think the last sentence should be: They have the meanings described in RFC3986. The same comment for section 10.2. 10.4. Sec-WebSocket-Key Status reserved; do not use outside WebSocket handshake This is not correct. According to RFC 3864, this field should contain the value "standard". The "do not use outside WebSocket handshake" can be moved to the "Related information" of the registration template. The same comment applies to sections 10.5-10.9 14. Normative References [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. Should this point to TLS 1.2? [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. This RFC just got obsoleted, so the reference needs to be updated. [WSAPI] Hickson, I., "The Web Sockets API", August 2010, . This must be an Informative reference. From dave@cridland.net Mon Mar 28 05:47:43 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC04C3A6A6E for ; Mon, 28 Mar 2011 05:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxSPyX4hnfhd for ; Mon, 28 Mar 2011 05:47:43 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id AF3013A683A for ; Mon, 28 Mar 2011 05:47:42 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 68A501168095; Mon, 28 Mar 2011 13:49:19 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRj4Oz5IpU20; Mon, 28 Mar 2011 13:49:18 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 16FF31168090; Mon, 28 Mar 2011 13:49:18 +0100 (BST) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <4126.1301316558.091020@puncture> Date: Mon, 28 Mar 2011 13:49:18 +0100 From: Dave Cridland To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , Server-Initiated HTTP , Greg Wilkins Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:47:43 -0000 On Mon Mar 28 00:53:52 2011, Iñaki Baz Castillo wrote: > Also, such DNS SRV query is *just* performed once: before > establishing > the connection with the WS server. ... for the first time. After that, it'll be cached like any other DNS query until the TTL expires, which can often reduce the latency to effectively zero. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From pmcmanus@mozilla.com Mon Mar 28 06:31:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C4463A691E for ; Mon, 28 Mar 2011 06:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EehAuwKsMIeB for ; Mon, 28 Mar 2011 06:31:01 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 3574A3A68EF for ; Mon, 28 Mar 2011 06:30:56 -0700 (PDT) Received: from dhcp-437f.meeting.ietf.org (dhcp-437f.meeting.ietf.org [130.129.67.127]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 7C13F10159 for ; Mon, 28 Mar 2011 09:32:33 -0400 (EDT) Message-ID: <4D908DEF.10203@mozilla.com> Date: Mon, 28 Mar 2011 15:32:31 +0200 From: Patrick McManus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> <4D8F6590.30808@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:31:09 -0000 On 3/28/11 1:29 AM, Greg Wilkins wrote: > > Firstly, I actually don't think we can prohibit non-101 responses. We > have consensus that before the 101 the handshake must be HTTP > compliant, and sending 400, 401, 301, 500, 503 are all HTTP compliant > responses that will very likely be seen no matter what we say here. > I basically agree with this - I would put it even stronger. Before the 101 this is HTTP and therefore the ietf websockets draft really doesn't have much to say other than what is already covered by HTTP. HTTP says if the response is 101 then start doing the upgraded protocol, otherwise this is still HTTP. The draft could use some clarification here. Personally I think to be successful UA's are going to need to implement 401s, redirects to pages that set cookies based on closed algorithms (and then probably redirect again), etc... Whether or not a UA chooses to chase a redirect (or prompt for auth, or whatever) is, as always, up to them. Adam, I'm interested in specific classes vulnerabilities you see there. Even in generalities. They might be arpopos for the security considerations section. From Gabriel.Montenegro@microsoft.com Mon Mar 28 06:42:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A573A696A for ; Mon, 28 Mar 2011 06:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.512 X-Spam-Level: X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugiILeLwKexe for ; Mon, 28 Mar 2011 06:42:58 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 5DDA83A6878 for ; Mon, 28 Mar 2011 06:42:58 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 28 Mar 2011 06:44:35 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.270.2; Mon, 28 Mar 2011 06:44:35 -0700 Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.217]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Mon, 28 Mar 2011 06:44:35 -0700 From: Gabriel Montenegro To: Patrick McManus , "hybi@ietf.org" Thread-Topic: [hybi] Clarify wheter HTTP responses other than 101 are valid Thread-Index: AQHL7HynyKmUwzqP/UG4ldPPAyyrxZRBlowAgAA9swCAAD3OgIAAN/YAgADriYD//4vN4A== Date: Mon, 28 Mar 2011 13:44:34 +0000 Message-ID: References: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> <4D8F6590.30808@gmail.com> <4D908DEF.10203@mozilla.com> In-Reply-To: <4D908DEF.10203@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:42:59 -0000 > > Firstly, I actually don't think we can prohibit non-101 responses. We > > have consensus that before the 101 the handshake must be HTTP > > compliant, and sending 400, 401, 301, 500, 503 are all HTTP compliant > > responses that will very likely be seen no matter what we say here. > > > I basically agree with this - I would put it even stronger. Before the > 101 this is HTTP and therefore the ietf websockets draft really doesn't h= ave > much to say other than what is already covered by HTTP. HTTP says if the > response is 101 then start doing the upgraded protocol, otherwise this is= still > HTTP. The draft could use some clarification here. I actually think that saying less gets us in less trouble. I'd delete all t= his text, because as long as we say that it is HTTP up to the point that th= e handshake is completed *successfully* then this is covered already by RFC= 2616: http://tools.ietf.org/html/rfc2616#section-10.3 on redirection 3xx: " The a= ction required MAY be carried out by the user agent..." The main point is that there is a MAY, so it is completely optional to the = client whether to heed such 3xx redirects. One could argue that httpbis has= even better language, but that MAY is enough for anybody not feeling entir= ely comfortable with heeding redirects to ignore them. > Personally I think to be successful UA's are going to need to implement 4= 01s, > redirects to pages that set cookies based on closed algorithms (and then > probably redirect again), etc... Whether or not a UA chooses to chase a r= edirect > (or prompt for auth, or whatever) is, as always, up to them. Exactly. Per RFC2616, no need to say anything more. > Adam, I'm interested in specific classes vulnerabilities you see there. > Even in generalities. They might be arpopos for the security consideratio= ns > section. This is a good point. The fact that clients have the option to respond call= s for some guidance or considerations. From ibc@aliax.net Mon Mar 28 06:45:56 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1053A6A59 for ; Mon, 28 Mar 2011 06:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMBlTfaaIPh3 for ; Mon, 28 Mar 2011 06:45:56 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 624503A6A55 for ; Mon, 28 Mar 2011 06:45:55 -0700 (PDT) Received: by qwg5 with SMTP id 5so2234993qwg.31 for ; Mon, 28 Mar 2011 06:47:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.63.154 with SMTP id b26mr2078495qci.163.1301320052644; Mon, 28 Mar 2011 06:47:32 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Mon, 28 Mar 2011 06:47:32 -0700 (PDT) In-Reply-To: References: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> <4D8F6590.30808@gmail.com> <4D908DEF.10203@mozilla.com> Date: Mon, 28 Mar 2011 15:47:32 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Gabriel Montenegro Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Patrick McManus Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:45:56 -0000 2011/3/28 Gabriel Montenegro : >> Personally I think to be successful UA's are going to need to implement = 401s, >> redirects to pages that set cookies based on closed algorithms (and then >> probably redirect again), etc... Whether or not a UA chooses to chase a = redirect >> (or prompt for auth, or whatever) is, as always, up to them. > > Exactly. Per RFC2616, no need to say anything more. The the draft should NOT say: Any status code other than 101 MUST be treated as a failure if semantics of that status code are not defined in the context of a WebSocket connection, and the websocket connection aborted --=20 I=C3=B1aki Baz Castillo From pmcmanus@mozilla.com Mon Mar 28 06:48:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD20E3A682B for ; Mon, 28 Mar 2011 06:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xt6EkvyxVk8 for ; Mon, 28 Mar 2011 06:48:36 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id F02003A680A for ; Mon, 28 Mar 2011 06:48:35 -0700 (PDT) Received: from dhcp-437f.meeting.ietf.org (dhcp-437f.meeting.ietf.org [130.129.67.127]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 32FE710159; Mon, 28 Mar 2011 09:50:13 -0400 (EDT) Message-ID: <4D909213.1030406@mozilla.com> Date: Mon, 28 Mar 2011 15:50:11 +0200 From: Patrick McManus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gabriel Montenegro References: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> <4D8F6590.30808@gmail.com> <4D908DEF.10203@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:48:36 -0000 On 3/28/11 3:44 PM, Gabriel Montenegro wrote: >> I basically agree with this - I would put it even stronger. Before the >> > I actually think that saying less gets us in less trouble. I'd delete all this text, because as long as we say that it is HTTP up to the point that the handshake is completed *successfully* then this is covered already by RFC2616: yes.. I got a little carried away with the "put it even stronger" bit. That was wrt wg discussion; the draft only needs to point at the HTTP RFC and remove the language about aborting a websocket connection that does not yet exist. From gregw@intalio.com Mon Mar 28 06:54:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CCDC3A6922 for ; Mon, 28 Mar 2011 06:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSdmeEpHNO6Z for ; Mon, 28 Mar 2011 06:54:50 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id CD8C43A687D for ; Mon, 28 Mar 2011 06:54:49 -0700 (PDT) Received: by vxg33 with SMTP id 33so2670609vxg.31 for ; Mon, 28 Mar 2011 06:56:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.168.8 with SMTP id zs8mr5658274vdb.184.1301320586912; Mon, 28 Mar 2011 06:56:26 -0700 (PDT) Received: by 10.52.155.71 with HTTP; Mon, 28 Mar 2011 06:56:26 -0700 (PDT) In-Reply-To: <4D907CC6.7080707@isode.com> References: <4D907CC6.7080707@isode.com> Date: Tue, 29 Mar 2011 00:56:26 +1100 Message-ID: From: Greg Wilkins To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Review of draft-ietf-hybi-thewebsocketprotocol-06.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:54:51 -0000 On 28 March 2011 23:19, Alexey Melnikov wrote: > 4.5.2. =A0Ping > > =A0The Ping message contains an opcode of 0x02. > > =A0Upon receipt of a Ping message, an endpoint MUST send a Pong message > =A0in response. =A0It SHOULD do so as soon as is practical. =A0The messag= e > =A0bodies of the Ping and Pong MUST be the same. > > I think this needs to clarify that a ping message doesn't contain any > Extension data and that "message bodies" is the Application data. Why can't a ping contain extension data? Or are you saying that we are clarifying that it is only the non extension payload data that is echoed? cheers From fielding@gbiv.com Mon Mar 28 09:16:43 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843543A6870 for ; Mon, 28 Mar 2011 09:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osMr3pcxHkHq for ; Mon, 28 Mar 2011 09:16:42 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id 7080A3A67E5 for ; Mon, 28 Mar 2011 09:16:42 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id C529A21DE77; Mon, 28 Mar 2011 09:18:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=Il74xYqXCb8ldRKo VnpJGJIF0uGwdbzupDckTnol2hwVqVTRAC7kxF4AlwLtMzpHdRzGwmdSWhgL+wE5 /3oUimOwwNB0z9L3NuE0SMEJRjfw1kVHBKKG9S+u0f0bSOvVuaxoI8FCKP5bR7SJ RD8JmYQXfg9Gcqcjh4yhPAdaEdk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=OhGZiAOyp5yTuYCg6MFfUj2w7PA=; b=FRLuay6H3Po/sUn8XP3L90ymo2n/ vBMWJJoat6ys5q+P/HWalH0f2exG9xswRXFsVmxrMPgdKpYn6Nk+IYLcWtwguJlV ZNyw32Ciy9ijDhhWHU8nZXBCUL661mQSBgpKDgNrx/lDF1aUox9cf1Isj7OuUIwS ZSDo9W3Ugi2pGW8= Received: from dhcp-13fd.meeting.ietf.org (dhcp-13fd.meeting.ietf.org [130.129.19.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 5524921DE14; Mon, 28 Mar 2011 09:18:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <4D908DEF.10203@mozilla.com> Date: Mon, 28 Mar 2011 18:18:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> <4D8F6590.30808@gmail.com> <4D908DEF.10203@mozilla.com> To: Patrick McManus X-Mailer: Apple Mail (2.1084) Cc: hybi@ietf.org Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:16:43 -0000 On Mar 28, 2011, at 3:32 PM, Patrick McManus wrote: > On 3/28/11 1:29 AM, Greg Wilkins wrote: >>=20 >> Firstly, I actually don't think we can prohibit non-101 responses. = We >> have consensus that before the 101 the handshake must be HTTP >> compliant, and sending 400, 401, 301, 500, 503 are all HTTP compliant >> responses that will very likely be seen no matter what we say here. >>=20 > I basically agree with this - I would put it even stronger. Before the = 101 this is HTTP and therefore the ietf websockets draft really doesn't = have much to say other than what is already covered by HTTP. HTTP says = if the response is 101 then start doing the upgraded protocol, otherwise = this is still HTTP. The draft could use some clarification here. That is exactly what I was going to write. If a client says that it is using HTTP, then it is governed by all of HTTP's client requirements and expected behavior. The same goes for servers that say they are sending an HTTP message. This does not change until after the Upgrade exchange is completed successfully. That said, there is nothing in HTTP that requires a client to follow a redirect -- that is a choice made by client configuration and/or nature. Any valid HTTP response can (and should) be understood without an implication that the websocket clients behave like a browser when handling those responses. ....Roy From jat@google.com Mon Mar 28 09:44:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE653A659C for ; Mon, 28 Mar 2011 09:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.939 X-Spam-Level: X-Spam-Status: No, score=-105.939 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJG5TQWks32G for ; Mon, 28 Mar 2011 09:44:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 41C6F3A6842 for ; Mon, 28 Mar 2011 09:44:14 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p2SGjpZ7003378 for ; Mon, 28 Mar 2011 09:45:51 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301330751; bh=/Q3STCXKZ9+h1Jj5nNRYYSBDNKE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=pby5i1LxgEVb7kfHLfh7q9NhbTCckrGF5XgNst0A5e7Knn1BuHsXkwOers1CLL2Vu HjFLvMYADd73Luf9GC/aw== Received: from gyd8 (gyd8.prod.google.com [10.243.49.200]) by wpaz24.hot.corp.google.com with ESMTP id p2SGjlEe005997 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 28 Mar 2011 09:45:50 -0700 Received: by gyd8 with SMTP id 8so1526897gyd.0 for ; Mon, 28 Mar 2011 09:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tOMgVHwShvbL5yNzp3qAUJNZGMp7fcLPozUS5gd+Qq4=; b=dlayLG+k7uzXcJHxdN/gyqmfi8XyVhOER4k6yg8uFteFBrTakIQqUeno4cfJfXuU8K AktZoqL22J3XnJsKoVYQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=kGiChJAlEiWLRmxigyZZzysOG20tpYYsCoDa3xcSKCCA61n9wcmwCTpRTtHZDX/F8Z aXaavbu++DwmVL1S1N7A== Received: by 10.150.209.1 with SMTP id h1mr4190498ybg.181.1301330750291; Mon, 28 Mar 2011 09:45:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Mon, 28 Mar 2011 09:45:30 -0700 (PDT) In-Reply-To: References: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> <4D8F6590.30808@gmail.com> <4D908DEF.10203@mozilla.com> From: John Tamplin Date: Mon, 28 Mar 2011 12:45:30 -0400 Message-ID: To: "Roy T. Fielding" Content-Type: multipart/alternative; boundary=000e0cd51c9e1b402f049f8dad78 X-System-Of-Record: true Cc: hybi@ietf.org, Patrick McManus Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:44:15 -0000 --000e0cd51c9e1b402f049f8dad78 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 28, 2011 at 12:18 PM, Roy T. Fielding wrote: > That is exactly what I was going to write. If a client says that it > is using HTTP, then it is governed by all of HTTP's client requirements > and expected behavior. The same goes for servers that say they are > sending an HTTP message. This does not change until after the Upgrade > exchange is completed successfully. > > That said, there is nothing in HTTP that requires a client to follow > a redirect -- that is a choice made by client configuration and/or > nature. Any valid HTTP response can (and should) be understood without > an implication that the websocket clients behave like a browser when > handling those responses. As long as it a WebSocket client/server that only cares about talking to WebSocket endpoints is acceptable under the spec, then I am fine with it. If a simple server implementation requires implementing a full HTTP server to handle all the possibilities before Upgrade, then I think that is a problem. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd51c9e1b402f049f8dad78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 28, 2011 at 12:18 PM, Roy T. Fieldin= g <fielding@gbiv.= com> wrote:
That is exactly what I was going to write. =C2=A0If a cli= ent says that it
is using HTTP, then it is governed by all of HTTP's client requirements=
and expected behavior. =C2=A0The same goes for servers that say they are sending an HTTP message. =C2=A0This does not change until after the Upgrade=
exchange is completed successfully.

That said, there is nothing in HTTP that requires a client to follow
a redirect -- that is a choice made by client configuration and/or
nature. =C2=A0Any valid HTTP response can (and should) be understood withou= t
an implication that the websocket clients behave like a browser when
handling those responses.

As long as it a W= ebSocket client/server that only cares about talking to WebSocket endpoints= is acceptable under the spec, then I am fine with it.

If a simple server implementation requires implementing a full HTTP se= rver to handle all the possibilities before Upgrade, then I think that is a= problem.

--
John A. Tamplin
Software Engineer (GWT),= Google
--000e0cd51c9e1b402f049f8dad78-- From bruce@callenish.com Mon Mar 28 09:56:17 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5036728C0FC for ; Mon, 28 Mar 2011 09:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PI+eTsAEphXa for ; Mon, 28 Mar 2011 09:56:16 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 7B8E13A6A1E for ; Mon, 28 Mar 2011 09:56:16 -0700 (PDT) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q4FlJ-000594-8n; Mon, 28 Mar 2011 09:57:53 -0700 Message-ID: <4D90BE10.8050801@callenish.com> Date: Mon, 28 Mar 2011 09:57:52 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Cc: Hybi Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:56:17 -0000 Is there any reason that the interaction of Websockets and DNS SRV could not be handled in a separate draft? That is how it is done in the SIP world between RFC3261 and RFC3263. Also, my interpretation of the SIP RFC is that it allows for DNS lookups that do not use DNS SRV (via a "local policy"). I'm not sure that using DNS SRV lookups should be a mandatory part of every websockets implementation. Recommended, sure, but not required. On 27/03/2011 10:23 AM, Iñaki Baz Castillo wrote: > Hi, DNS SRV [*] is a mechanism for providing load-balancing and > failover at client side. It's very common in modern communication > protocols as SIP or XMPP. It's not used in HTTP, most probably because > HTTP was created before SRV records, and when SRV was specified it was > too late for including it into HTTP protocol. However WebSocket is a > new protocol and could take advantage of it. > > For now, WebSocket draft just provide a host (hostname or IP) and port > for the client to communicate with a WS server. Now that WS is still a > draft it would be a good moment to include DNS SRV into WebSocket. > Please consider it. > > Usage example: > > - A web page includes a WS connection to some-domain.org. > > - The web browser performs a DNS SRV query for > _ws._tcp.some-domain.org and gets the following SRV records: > > _ws._tcp.some-domain.org. IN SRV 1 60 80 ws1.some-domain.org. > _ws._tcp.some-domain.org. IN SRV 1 40 80 ws2.some-domain.org. > _ws._tcp.some-domain.org. IN SRV 2 0 8080 ws3.some-domain.org. > > - The client would then choose between the two records with best > priority (1) taking into account their weight (60 and 40), so for > example ws1.some-domain.org:80. > > - In case such destination is unreachable the client would take the > second one (ws2.some-domain.org:80). > > - If also unreachable, then the third option (with less priority) > would be chosen (ws3.some-domain.org:8080). > > NOTE: In case of WS over SSL/TLS, the SRV query would be > _wss._tcp.some-domain.org. > > In this way, WS gets load balancing (based on SRV records weitgh) and > failover (based on SRV records priority). Of course, in case there is > not SRV record for _ws._tcp.some-domain.org, the client would then > perform a common DNS A query for some-domain.org as usual. So SRV > records are not mandatory (this is also true in SIP and XMPP). > > IMHO, this is very useful and should be part of any new communication > protocol in Internet. But it should be defined as part of the > WebSocket specification from the beginning rather than being a future > addition (after WS is widely implemented it will be hard to introduce > it). > > Best regards. > > > [*] DNS SRV: http://tools.ietf.org/html/rfc2782 > > From ibc@aliax.net Mon Mar 28 10:03:46 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7D43A6820 for ; Mon, 28 Mar 2011 10:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_72=0.6, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDEPXdvA1aID for ; Mon, 28 Mar 2011 10:03:44 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 4D9483A659C for ; Mon, 28 Mar 2011 10:03:44 -0700 (PDT) Received: by qyk29 with SMTP id 29so1282052qyk.10 for ; Mon, 28 Mar 2011 10:05:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.63.154 with SMTP id b26mr2314737qci.163.1301331912906; Mon, 28 Mar 2011 10:05:12 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Mon, 28 Mar 2011 10:05:12 -0700 (PDT) In-Reply-To: <4D90BE10.8050801@callenish.com> References: <4D90BE10.8050801@callenish.com> Date: Mon, 28 Mar 2011 19:05:12 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bruce Atherton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:03:46 -0000 2011/3/28 Bruce Atherton : > Is there any reason that the interaction of Websockets and DNS SRV could = not > be handled in a separate draft? That is how it is done in the SIP world > between RFC3261 and RFC3263. Both are two different RFC, true, but RFC 3261 references RFC 3263 for resolving server location based on DNS SRV. > Also, my interpretation of the SIP RFC is that it allows for DNS lookups > that do not use DNS SRV (via a "local policy"). I'm not sure that using D= NS > SRV lookups should be a mandatory part of every websockets implementation= . > Recommended, sure, but not required. The point here is that DNS SRV is not mandatory. For example: - The JS in a web page must open a WS connection with ws://mydomain.org. - Then the WS client performs a SRV query for domain=3Dmydomain.org, service=3Dws and transport=3Dtcp. - If such DNS SRV record exists, then the client chooses one of the entries (based on weight and priority) and performs a DNS A query for the domain of the chosen entry, and then connects to the resolver IP and the port indicated in the chosen SRV entry. - In case such DNS SRV doesn't exist, then the WS client should perform a DNS A query for mydomain.org, and connect to the resolved IP and default port (80 for ws:// and 443 for wss://). Also, in case the ws URI does contain a port (i.e: ws://mydomain.org:8080) then the WS client MUST not perform a SRV query, but just a DNS A query for mydomaing.org and connect to the resolved IP and port 8080 (as usual). So the WS client should check for the existence of a SRV record for the given domain (if no port is given), but the SRV record could exist or not. It's very flexible but, of course, in order to work properly, it should be mandatory for WS clients. --=20 I=C3=B1aki Baz Castillo From derhoermi@gmx.net Mon Mar 28 10:09:31 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32D828C0F6 for ; Mon, 28 Mar 2011 10:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2F6hIRI--eV for ; Mon, 28 Mar 2011 10:09:30 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 02C793A682A for ; Mon, 28 Mar 2011 10:09:29 -0700 (PDT) Received: (qmail invoked by alias); 28 Mar 2011 17:11:05 -0000 Received: from dslb-094-222-129-148.pools.arcor-ip.net (EHLO HIVE) [94.222.129.148] by mail.gmx.net (mp016) with SMTP; 28 Mar 2011 19:11:05 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX187fSkD3NU7nZVls/z67HeckjdCrbaP9vOOCHOQxM LD+57cDPAIsFBN From: Bjoern Hoehrmann To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Mon, 28 Mar 2011 19:11:11 +0200 Message-ID: References: <4D90BE10.8050801@callenish.com> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Hybi Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:09:31 -0000 * Iñaki Baz Castillo wrote: >So the WS client should check for the existence of a SRV record for >the given domain (if no port is given), but the SRV record could exist >or not. It's very flexible but, of course, in order to work properly, >it should be mandatory for WS clients. It would seem very unlikely that all client implementations will do this (because the feature is obscure to many, lack of test servers, lack of proper DNS libraries that make this easy, not getting around to it, not caring, and so on). As I understand it, not supporting SRV lookups is a common problem with simpler XMPP implementations, for instance. So, if this was mandatory for Websocket clients, we'd likely be looking at many non-compliant implementations. Putting it the other way around, usually people don't implement features just because they are formally required. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From fielding@gbiv.com Mon Mar 28 10:18:23 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538EA3A6842 for ; Mon, 28 Mar 2011 10:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA7YXXOn6xXI for ; Mon, 28 Mar 2011 10:18:22 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 9A5F43A659C for ; Mon, 28 Mar 2011 10:18:20 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 4C92977805F; Mon, 28 Mar 2011 10:19:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=N4BObq2mGMYBN4XB EatHWFV7N2L/VCVtraNy2HrMvPOXvvCD8w+pB/fAoU5neMP2yZeyEGgCvkvkT6Xf AA5UEDO4arY88+bnXJccsu3/9NMSr0rfb29Tw5duklW5rEZGeQn3T2I7rlIPN5dc 2eR0NJfWqKcWJM8zkp5QxWQPOiM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=d52baG5JnvesW8Q9XH+8d2B5YKI=; b=UCyjvDBPX9XDpXSMqwoLpjul5A6+ FW/QPCIVWk54ZdXhRyGwyHobbBY9WsTDdoM39wDQr0+YaNt1U1of7CwysS1VRSB7 zGqK1GgLLrRQRmXDpQXEUIvXSYdr0VsAwCJAJTeA+8ArgD/29OhGwFNbCuRQgYxK gmGhH1YC0t5GwZU= Received: from dhcp-13fd.meeting.ietf.org (dhcp-13fd.meeting.ietf.org [130.129.19.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 78A05778057; Mon, 28 Mar 2011 10:19:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: Date: Mon, 28 Mar 2011 19:19:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5BB8D212-3D5D-459C-8380-8A04BF9115F4@gbiv.com> References: <8B0A9FCBB9832F43971E38010638454F04027B917C@SISPE7MB1.commscope.com> <4D8F6590.30808@gmail.com> <4D908DEF.10203@mozilla.com> To: John Tamplin X-Mailer: Apple Mail (2.1084) Cc: hybi@ietf.org, Patrick McManus Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:18:23 -0000 On Mar 28, 2011, at 6:45 PM, John Tamplin wrote: > If a simple server implementation requires implementing a full HTTP = server to handle all the possibilities before Upgrade, then I think that = is a problem. A full HTTP server implementation is only as complicated as the resources it chooses to supply answers for. I can write one in a dozen lines of perl (without using LWP). It is certainly far less complex than figuring out how to respond to a WS handshake, so don't worry about that. ....Roy From dave@cridland.net Mon Mar 28 10:18:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3173A6842 for ; Mon, 28 Mar 2011 10:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-waIHDWG3Fd for ; Mon, 28 Mar 2011 10:18:35 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id B65323A659C for ; Mon, 28 Mar 2011 10:18:34 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id EEDA3116808F; Mon, 28 Mar 2011 18:20:10 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CONRR4iwM-9w; Mon, 28 Mar 2011 18:20:09 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 2C4481168067; Mon, 28 Mar 2011 18:20:09 +0100 (BST) References: <4D90BE10.8050801@callenish.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <4126.1301332809.179090@puncture> Date: Mon, 28 Mar 2011 18:20:09 +0100 From: Dave Cridland To: Bjoern Hoehrmann , Server-Initiated HTTP , =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:18:36 -0000 On Mon Mar 28 18:11:11 2011, Bjoern Hoehrmann wrote: > * Iñaki Baz Castillo wrote: > >So the WS client should check for the existence of a SRV record for > >the given domain (if no port is given), but the SRV record could > exist > >or not. It's very flexible but, of course, in order to work > properly, > >it should be mandatory for WS clients. > > It would seem very unlikely that all client implementations will do > this > (because the feature is obscure to many, lack of test servers, lack > of > proper DNS libraries that make this easy, not getting around to it, > not > caring, and so on). As I understand it, not supporting SRV lookups > is a > common problem with simpler XMPP implementations, for instance. So, > if > this was mandatory for Websocket clients, we'd likely be looking at > many > non-compliant implementations. Putting it the other way around, > usually > people don't implement features just because they are formally > required. Your understanding is probably a little outdated. While it's true that there exist some XMPP libraries and clients which cannot perform SRV lookups, these are very rare nowadays, and really restricted to simple utility scripts. In the WebSocket world, there are very many fewer client implementations to worry about, which will also make it easier. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From bruce@callenish.com Mon Mar 28 10:24:01 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DE5E28C0F1 for ; Mon, 28 Mar 2011 10:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDyH-PfOWdZH for ; Mon, 28 Mar 2011 10:24:00 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 740FA28B56A for ; Mon, 28 Mar 2011 10:24:00 -0700 (PDT) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q4GC7-0008E0-VE; Mon, 28 Mar 2011 10:25:37 -0700 Message-ID: <4D90C488.4060407@callenish.com> Date: Mon, 28 Mar 2011 10:25:28 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4D90BE10.8050801@callenish.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Cc: Hybi Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:24:01 -0000 On 28/03/2011 10:05 AM, Iñaki Baz Castillo wrote: > > Both are two different RFC, true, but RFC 3261 references RFC 3263 for > resolving server location based on DNS SRV. Sure, but because it was in a different draft the specifics of what it says has no impact on RFC3261. It could have talked about only using A records and RFC3261 could remain unchanged. > The point here is that DNS SRV is not mandatory. We are talking about two different kinds of "mandatory". You are saying that it is not mandatory for there to be DNS SRV records. I am saying it should not be mandatory for a Websockets client to look up DNS SRV records before looking up DNS A records. Not everyone will want or need the extra complexity. From alexey.melnikov@isode.com Mon Mar 28 10:27:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3303128C122 for ; Mon, 28 Mar 2011 10:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJMYAV796YdK for ; Mon, 28 Mar 2011 10:27:07 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4933428C11C for ; Mon, 28 Mar 2011 10:27:07 -0700 (PDT) Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 28 Mar 2011 18:28:44 +0100 Message-ID: <4D90C539.2040803@isode.com> Date: Mon, 28 Mar 2011 19:28:25 +0200 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Greg Wilkins References: <4D907CC6.7080707@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Review of draft-ietf-hybi-thewebsocketprotocol-06.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:27:08 -0000 Hi Greg, Greg Wilkins wrote: >On 28 March 2011 23:19, Alexey Melnikov wrote: > > >>4.5.2. Ping >> >> The Ping message contains an opcode of 0x02. >> >> Upon receipt of a Ping message, an endpoint MUST send a Pong message >> in response. It SHOULD do so as soon as is practical. The message >> bodies of the Ping and Pong MUST be the same. >> >>I think this needs to clarify that a ping message doesn't contain any >>Extension data and that "message bodies" is the Application data. >> >> >Why can't a ping contain extension data? > >Or are you saying that we are clarifying that it is only the non >extension payload data that is echoed? > I just thought that use of "body" was unclear. I am Ok if it refers to both the application data together with the extension data. From ibc@aliax.net Mon Mar 28 10:28:41 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD7128C0F1 for ; Mon, 28 Mar 2011 10:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_72=0.6, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7ytawarHB1M for ; Mon, 28 Mar 2011 10:28:39 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 5F4303A689A for ; Mon, 28 Mar 2011 10:28:39 -0700 (PDT) Received: by qwg5 with SMTP id 5so2436720qwg.31 for ; Mon, 28 Mar 2011 10:30:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.63.154 with SMTP id b26mr2341216qci.163.1301333416752; Mon, 28 Mar 2011 10:30:16 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Mon, 28 Mar 2011 10:30:16 -0700 (PDT) In-Reply-To: References: <4D90BE10.8050801@callenish.com> Date: Mon, 28 Mar 2011 19:30:16 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bjoern Hoehrmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:28:42 -0000 2011/3/28 Bjoern Hoehrmann : > * I=C3=B1aki Baz Castillo wrote: >>So the WS client should check for the existence of a SRV record for >>the given domain (if no port is given), but the SRV record could exist >>or not. It's very flexible but, of course, in order to work properly, >>it should be mandatory for WS clients. > > It would seem very unlikely that all client implementations will do this > (because the feature is obscure to many, lack of test servers, lack of > proper DNS libraries that make this easy, not getting around to it, not > caring, and so on). As I understand it, not supporting SRV lookups is a > common problem with simpler XMPP implementations, for instance. So, if > this was mandatory for Websocket clients, we'd likely be looking at many > non-compliant implementations. Putting it the other way around, usually > people don't implement features just because they are formally required. A WS client could not support SRV and still work. Example: - For domain mydomain.org there are a DNS SRV record and 3 DNS A records: SRV record: _ws._tcp.mydomain.org. IN SRV 1 0 80 mydomain.org. _ws._tcp.mydomain.org. IN SRV 2 0 8080 backup.mydomain.org. A records: mydomain.org. 1.1.1.1 backup.mydomain.org. 1.1.1.2 - The web page indicates the following WS URI: ws://mydomain.org. case 1) SRV capable WS client ----------------------------------------------------------------------- - It performs a SRV query for domain=3Dmydomain.org, service=3Dws and trans= port=3Dtcp. - It gets the SRV record with two entries and chooses the first one (with best priority). - So it performs a DNS A query for domain "mydomain.org" and gets 1.1.1.1. - Then it connects to 1.1.1.1:80. - In case the server is unreachable, the client tries the second location by performing a DNS A query for backup.mydomain.org and gets 1.1.1.2, so it connects to 1.1.1.2:8080 (failover, oh yeah !!!). case 2) Non-SRV capable WS client ----------------------------------------------------------------------- - It performs a DNS A query for domain=3Dmydomain.org and gets 1.1.1.1. - Then it connects to 1.1.1.1:80. - In case the server is unreachable the client cannot do failover due to its limitation (it doesn't support SRV, sorry). So, as you can see, it's not fully required that the client supports SRV, but if it does, it can take COOL advantages from it. --=20 I=C3=B1aki Baz Castillo From theturtle32@gmail.com Mon Mar 28 12:21:47 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E39AD3A6811 for ; Mon, 28 Mar 2011 12:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.145 X-Spam-Level: X-Spam-Status: No, score=-3.145 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nr5HFPXijwW for ; Mon, 28 Mar 2011 12:21:46 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 815FC3A67FD for ; Mon, 28 Mar 2011 12:21:46 -0700 (PDT) Received: by iye19 with SMTP id 19so3900003iye.31 for ; Mon, 28 Mar 2011 12:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=o+Si3JxATeKX6pg4JKv5usV/ZCpHdnMmo1yCdrfLFtg=; b=k1pdBa7SE/CzCoeBz2wyfgItpeTwtDp545bZHsmyaXIKRJ3YJeB4kx+4idn5PstOsg bLKUHZNnLo8wGzYLb1Kbw3s+9vDbyZJKPizSMgYwclSgCsZuU+xNV2qHldLjtO+FKAG3 1drrkTjfpu5i4bNTE8XWlCqgOLF8+7BftMocs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YPUnUxWoBrVgXo/MEM5w07z+7c7qO0XLp9Pee5p6+BBN9Zgi1JW03KtdL7yAxiZdI2 +eZtvljy6r4kzlRkHBrMzDC/hFFdbu/8aCMkdBmME4WcW/UuYAzEVx3iZbtjvCbWP6X+ pWIMfw86Zk08MjwRXj3FW/1Op36vEbS74aww8= MIME-Version: 1.0 Received: by 10.231.180.25 with SMTP id bs25mr3788280ibb.151.1301340202837; Mon, 28 Mar 2011 12:23:22 -0700 (PDT) Received: by 10.231.168.202 with HTTP; Mon, 28 Mar 2011 12:23:22 -0700 (PDT) Date: Mon, 28 Mar 2011 12:23:22 -0700 Message-ID: From: Brian To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] AS3WebSocket Library and Test App X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 19:21:48 -0000 Hi, all! My in-progress ActionScript 3 WebSocket-06 client library is now up on GitHub, in case any of you might find it a helpful sparring-partner for your server implementations. You can find it here: https://github.com/worlize/AS3WebSocket There are still a few things missing that I intend to address soon, and it hasn't undergone extensive testing yet. I also built a test application with Adobe Air that knows about a couple of the libwebsocket-test-server subprotocols. You can grab a pre-built .air binary of that app under the "Downloads" section of the GitHub repo. Screenshot showing AS3WebSocket interoperating with Andy Green's test page: http://blog.worlize.com/media/as3websocket.png Current Features: - Support for -06 draft including the handshake, framing, and masking - Support for the deflate-stream extension Known Issues: - Fragmentation is not yet supported - There is no user-provided extension API implemented - No wss:// support yet - Only the libwebsocket-test-server subprotocols mentioned have been tested so far - Only tested in Adobe Air, not yet in Flash Player.. probably have to add a little code to make it check for a policy file for Flash Player. - URL parsing could be more robust - Server response header parsing is a bit brittle Cheers, Brian From theturtle32@gmail.com Mon Mar 28 12:23:03 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177BD3A68F2 for ; Mon, 28 Mar 2011 12:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.129 X-Spam-Level: X-Spam-Status: No, score=-3.129 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y95Q+9GdBNuj for ; Mon, 28 Mar 2011 12:23:01 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 897DD3A67C1 for ; Mon, 28 Mar 2011 12:23:01 -0700 (PDT) Received: by iwn39 with SMTP id 39so3941771iwn.31 for ; Mon, 28 Mar 2011 12:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=im2Z62Rrcz6BoHn41gN1hz1SEJT1wtiDiwtoZHgCmwE=; b=vjlP75gEb0k4DUH4dc7RGOQEPku4G+1IbzvKKwyYibPfhaVqxnx6KHvlFXVqSl77lw DFg0ivnPpiDRSFdKBrXlroBn/Pn7aK7q4X2pDrrhw5k5yBXi0TScuo8djk7DfrwUDVgp 2zJqlkYruxmd2Ua8KiEhRk4ppGOO39NVOSPTs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ZfmtnOgHqC/cMsaM49JtpKQHfcz6Y7LGkCxYB8Xp8LPcuqMGFj5mBM6Q3ZpIhown1a bzmBP7M+UIbwZbADflIunUT/wbh/98CpTC044Mm2Z8bmA/ACzpI5J9wpt9m6lqsAbiEs hY4H1El3k+rS6V5/WIXrawMSIlHarRsQh1hoU= MIME-Version: 1.0 Received: by 10.231.117.93 with SMTP id p29mr4576017ibq.126.1301340279044; Mon, 28 Mar 2011 12:24:39 -0700 (PDT) Received: by 10.231.168.202 with HTTP; Mon, 28 Mar 2011 12:24:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Mar 2011 12:24:38 -0700 Message-ID: From: Brian To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] AS3WebSocket Library and Test App X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 19:23:03 -0000 Oops, sorry for the extra occurrence of this mail. I mistakenly thought my first attempt hadn't gone through. Apologies, Brian On Mon, Mar 28, 2011 at 12:23 PM, Brian wrote: > Hi, all! > > My in-progress ActionScript 3 WebSocket-06 client library is now up on > GitHub, in case any of you might find it a helpful sparring-partner > for your server implementations. =A0You can find it here: > https://github.com/worlize/AS3WebSocket > > There are still a few things missing that I intend to address soon, > and it hasn't undergone extensive testing yet. =A0I also built a test > application with Adobe Air that knows about a couple of the > libwebsocket-test-server subprotocols. =A0You can grab a pre-built .air > binary of that app under the "Downloads" section of the GitHub repo. > > Screenshot showing AS3WebSocket interoperating with Andy Green's test > page: http://blog.worlize.com/media/as3websocket.png > > Current Features: > - Support for -06 draft including the handshake, framing, and masking > - Support for the deflate-stream extension > > Known Issues: > - Fragmentation is not yet supported > - There is no user-provided extension API implemented > - No wss:// support yet > - Only the libwebsocket-test-server subprotocols mentioned have been > tested so far > - Only tested in Adobe Air, not yet in Flash Player.. probably have to > add a little code to make it check for a policy file for Flash Player. > - URL parsing could be more robust > - Server response header parsing is a bit brittle > > > Cheers, > Brian > From ietf@adambarth.com Mon Mar 28 13:33:10 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A80CA3A6902 for ; Mon, 28 Mar 2011 13:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmxjdIzrrkE1 for ; Mon, 28 Mar 2011 13:33:09 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id A4F683A68D2 for ; Mon, 28 Mar 2011 13:33:09 -0700 (PDT) Received: by vws12 with SMTP id 12so3075178vws.31 for ; Mon, 28 Mar 2011 13:34:47 -0700 (PDT) Received: by 10.52.167.230 with SMTP id zr6mr6118717vdb.6.1301344486922; Mon, 28 Mar 2011 13:34:46 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by mx.google.com with ESMTPS id h18sm2361521vbj.11.2011.03.28.13.34.45 (version=SSLv3 cipher=OTHER); Mon, 28 Mar 2011 13:34:46 -0700 (PDT) Received: by qwg5 with SMTP id 5so2562658qwg.31 for ; Mon, 28 Mar 2011 13:34:45 -0700 (PDT) Received: by 10.224.201.130 with SMTP id fa2mr3819190qab.364.1301344485228; Mon, 28 Mar 2011 13:34:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.89.83 with HTTP; Mon, 28 Mar 2011 13:34:14 -0700 (PDT) From: Adam Barth Date: Mon, 28 Mar 2011 13:34:14 -0700 Message-ID: To: Patrick McManus Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: [hybi] Why redirects are a bad for the security of WebSockets (was Re: Clarify wheter HTTP responses other than 101 are valid) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 20:33:10 -0000 On Mon, Mar 28, 2011 at 6:32 AM, Patrick McManus wro= te: > On 3/28/11 1:29 AM, Greg Wilkins wrote: >> Firstly, I actually don't think we can prohibit non-101 responses. =A0We >> have consensus that =A0before the 101 the handshake must be HTTP >> compliant, and sending 400, 401, 301, 500, 503 are all HTTP compliant >> responses that will very likely be seen no matter what we say here. > > I basically agree with this - I would put it even stronger. Before the 10= 1 > this is HTTP and therefore the ietf websockets draft really doesn't have > much to say other than what is already covered by HTTP. HTTP says if the > response is 101 then start doing the upgraded protocol, otherwise this is > still HTTP. The draft could use some clarification here. The WebSocket protocol is a profile of HTTP. WebSockets is free to define as small a profile as we choose. In particular, we're free to close the connection on non-101 status codes. > Personally I think to be successful UA's are going to need to implement > 401s, redirects to pages that set cookies based on closed algorithms (and > then probably redirect again), etc... Whether or not a UA chooses to chas= e a > redirect (or prompt for auth, or whatever) is, as always, up to them. I'm skeptical of this claim. I believe we can implement quite successful user agents permitting only the 101 status. > Adam, I'm interested in specific classes vulnerabilities you see there. E= ven > in generalities. They might be arpopos for the security considerations > section. Let's focus on redirects for a bit because those are some of the most problematic. Redirects introduce significant complexity in HTTP. For example, redirects have been responsible for a large number of security vulnerabilities in Firefox (and every other browser). By introducing redirects into the WebSockets protocol, we're forcing developers using WebSockets to deal with their complexities, and they're going to screw it up. Consider the following code: var url =3D if (!url.startsWith("wss://example.com/")) return; var socket =3D new WebSocket(url); socket.onopen =3D function () { [... interact with socket ...] }; Reading this code, it's quite natural to assume that sending and receiving information on socket will actually communicate with example.com. For example, I might send confidential information to example.com or rely upon the integrity of information received from example.com. However, if example.com has has an open redirector (as is extremely common on the Internet), this assumption is incorrect and leads to vulnerabilities. Now, we can wring our hands and claim that this sort of issue isn't our problem, but it is. Simply warning folks about these traps in Security Considerations is just passing the buck. Instead, we shouldn't add this complexity to WebSockets at this time. We can always change out minds and add support for redirects in the future, but we can never remove support once added. Adam From gregw@intalio.com Mon Mar 28 13:38:09 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7F0A3A6A2B for ; Mon, 28 Mar 2011 13:38:09 -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=[AWL=-0.322, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUWtYwq8rXVK for ; Mon, 28 Mar 2011 13:38:09 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 16B733A6902 for ; Mon, 28 Mar 2011 13:38:09 -0700 (PDT) Received: by vxg33 with SMTP id 33so3078839vxg.31 for ; Mon, 28 Mar 2011 13:39:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.4 with SMTP id 4mr2932569vda.104.1301344786491; Mon, 28 Mar 2011 13:39:46 -0700 (PDT) Received: by 10.52.155.71 with HTTP; Mon, 28 Mar 2011 13:39:46 -0700 (PDT) In-Reply-To: References: <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com> Date: Tue, 29 Mar 2011 07:39:46 +1100 Message-ID: From: Greg Wilkins To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Thomson, Martin" , Hybi Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 20:38:10 -0000 On 28 March 2011 19:34, I=F1aki Baz Castillo wrote: > Also, I've explained that SRV is not just for "provide name-based > discovery for a service". SRV provides *Real* load-balancing and > failover. This doesn't exist in HTTP (in which just a hack is used: a > DNS A record with different IP's). So the problem using SRV for ws is that ws starts with a HTTP connection, which may be existing and may be used for other HTTP requests if the handshake fails. So there is not much we can do to tell clients that they should use SRV when creating the HTTP connection. So why doesn't HTTP use it? cheers From dave@cridland.net Mon Mar 28 13:52:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED7728C107 for ; Mon, 28 Mar 2011 13:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj3-W+4l9hFO for ; Mon, 28 Mar 2011 13:52:20 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 855E83A6A69 for ; Mon, 28 Mar 2011 13:52:16 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 70CF91168087; Mon, 28 Mar 2011 21:53:43 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rfCU33wYAN0; Mon, 28 Mar 2011 21:53:41 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id A2D3F1168067; Mon, 28 Mar 2011 21:53:41 +0100 (BST) References: <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <4126.1301345621.644965@puncture> Date: Mon, 28 Mar 2011 21:53:41 +0100 From: Dave Cridland To: Greg Wilkins , "Thomson\, Martin" , Server-Initiated HTTP , =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 20:52:22 -0000 On Mon Mar 28 21:39:46 2011, Greg Wilkins wrote: > On 28 March 2011 19:34, Iñaki Baz Castillo wrote: > > Also, I've explained that SRV is not just for "provide name-based > > discovery for a service". SRV provides *Real* load-balancing and > > failover. This doesn't exist in HTTP (in which just a hack is > used: a > > DNS A record with different IP's). > > So the problem using SRV for ws is that ws starts with a HTTP > connection, > which may be existing and may be used for other HTTP requests if the > handshake fails. > > Right. Adam's going to hate me, but this would be a perfect use-case for a redirect. But in any case, we can say that this is a MUST NOT. I appreciate this is somewhat bending the rules of HTTP compatibility, but I think it's worthwhile for the benefits that SRV records give. > So there is not much we can do to tell clients that they should use > SRV when creating the HTTP connection. > > So why doesn't HTTP use it? HTTP doesn't use it primarily because it was a concept not familiar to the designers of HTTP when it was created, and by the time the idea was put forward it was too late to change, since people had deployed web services on their domain roots (ie, cridland.net as well as www.cridland.net), and therefore there was no utility in a fallback to A. (SRV records themselves were first specified in RFC 2052, back in 1996, but the mechanism is a generalization of MX records, of course. Of some note is that the arguments being raised against SRV records here are also all applicable to MX records, which have been deployed successfully since the early 90's, and probably before). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From gregw@intalio.com Mon Mar 28 14:04:33 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 589AA28C104 for ; Mon, 28 Mar 2011 14:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPcowvuecJU9 for ; Mon, 28 Mar 2011 14:04:32 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4A14228C0F0 for ; Mon, 28 Mar 2011 14:04:31 -0700 (PDT) Received: by vws12 with SMTP id 12so3102577vws.31 for ; Mon, 28 Mar 2011 14:06:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.168.8 with SMTP id zs8mr501214vdb.184.1301346368648; Mon, 28 Mar 2011 14:06:08 -0700 (PDT) Received: by 10.52.155.71 with HTTP; Mon, 28 Mar 2011 14:06:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Mar 2011 08:06:08 +1100 Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Patrick McManus Subject: Re: [hybi] Why redirects are a bad for the security of WebSockets (was Re: Clarify wheter HTTP responses other than 101 are valid) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 21:04:33 -0000 On 29 March 2011 07:34, Adam Barth wrote: > Consider the following code: > > var url =3D > > if (!url.startsWith("wss://example.com/")) > =A0return; > > var socket =3D new WebSocket(url); > socket.onopen =3D function () { > =A0[... interact with socket ...] > }; > > Reading this code, it's quite natural to assume that sending and > receiving information on socket will actually communicate with > example.com. =A0For example, I might send confidential information to > example.com or rely upon the integrity of information received from > example.com. =A0However, if example.com has has an open redirector (as > is extremely common on the Internet), this assumption is incorrect and > leads to vulnerabilities. > > Now, we can wring our hands and claim that this sort of issue isn't > our problem, but it is. =A0Simply warning folks about these traps in > Security Considerations is just passing the buck. =A0Instead, we > shouldn't add this complexity to WebSockets at this time. =A0We can > always change out minds and add support for redirects in the future, > but we can never remove support once added. Adam, I don't think it is "our problem". I think it is a "W3C/WHATWG HTML-5 WG problem". This is essentially an API issue for the browser websocket object. There are plenty of ways around this (adding optional follow redirects, exposing redirect responses etc. etc.), but I think it is the W3C and WHATWG HTML-5 working groups that should be where such matters are decided. As a web developer I really rather not have to go without redirection and other common auth methods - and I take responsibility for my servers not being open redirectors..... but would understand if the W3C/WHATWG decided not to support these features - at least initially. However, we should make the protocol such that if/when the API does support these features, then it will only be an in browser change and not an update of the protocol. cheers From mcmanus@ducksong.com Mon Mar 28 15:37:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC1203A6A8F for ; Mon, 28 Mar 2011 15:37:04 -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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGoQX+X12L+s for ; Mon, 28 Mar 2011 15:37:03 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id CD6A23A6A87 for ; Mon, 28 Mar 2011 15:37:03 -0700 (PDT) Received: from dhcp-42ae.meeting.ietf.org (dhcp-42ae.meeting.ietf.org [130.129.66.174]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 5888B10178 for ; Mon, 28 Mar 2011 18:38:41 -0400 (EDT) Message-ID: <4D910DF0.4070204@ducksong.com> Date: Tue, 29 Mar 2011 00:38:40 +0200 From: Patrick McManus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] Why redirects are a bad for the security of WebSockets (was Re: Clarify wheter HTTP responses other than 101 are valid) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:37:04 -0000 Hi Adam, I really appreciate you spelling this out - it helps the WG. On 3/28/11 10:34 PM, Adam Barth wrote: > example.com. However, if example.com has has an open redirector (as > is extremely common on the Internet), this assumption is incorrect and > leads to vulnerabilities. > I know you won't agree, but for the wg list I don't see how this expands the threat model when compared to all the other bugs and vulnerabilities that might be present (or not) on example.com when we interact with it. I'm not saying its not our problem, I'm just saying it is more or less par for level of vulnerability we already have by connecting to that host. There are auth patterns using redirect that I think would be useful to support. The websockets API wont be able to pass the redir info to the JS on failure so we can't just bump the issue out. Plus I think having a full fledged http bootstrap without caveat and exception is a good thing from a modeling point of view for a lot of the same reasons I think masking the whole client->server request stream is a better model. From ietf@adambarth.com Mon Mar 28 15:46:16 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484B83A6A83 for ; Mon, 28 Mar 2011 15:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v08m-3Lf1VgE for ; Mon, 28 Mar 2011 15:46:15 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 4A6723A6948 for ; Mon, 28 Mar 2011 15:46:15 -0700 (PDT) Received: by qwg5 with SMTP id 5so2637696qwg.31 for ; Mon, 28 Mar 2011 15:47:52 -0700 (PDT) Received: by 10.224.201.74 with SMTP id ez10mr3972857qab.372.1301352472777; Mon, 28 Mar 2011 15:47:52 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by mx.google.com with ESMTPS id t17sm1872796qcs.35.2011.03.28.15.47.51 (version=SSLv3 cipher=OTHER); Mon, 28 Mar 2011 15:47:51 -0700 (PDT) Received: by qyk7 with SMTP id 7so2452958qyk.10 for ; Mon, 28 Mar 2011 15:47:51 -0700 (PDT) Received: by 10.224.201.130 with SMTP id fa2mr3919460qab.364.1301352471073; Mon, 28 Mar 2011 15:47:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.89.83 with HTTP; Mon, 28 Mar 2011 15:47:21 -0700 (PDT) In-Reply-To: <4D910DF0.4070204@ducksong.com> References: <4D910DF0.4070204@ducksong.com> From: Adam Barth Date: Mon, 28 Mar 2011 15:47:21 -0700 Message-ID: To: Patrick McManus Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Why redirects are a bad for the security of WebSockets (was Re: Clarify wheter HTTP responses other than 101 are valid) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:46:16 -0000 On Mon, Mar 28, 2011 at 3:38 PM, Patrick McManus wro= te: > Hi Adam, I really appreciate you spelling this out - it helps the WG. > > On 3/28/11 10:34 PM, Adam Barth wrote: >> example.com. =A0However, if example.com has has an open redirector (as >> is extremely common on the Internet), this assumption is incorrect and >> leads to vulnerabilities. > > I know you won't agree, but for the wg list I don't see how this expands = the > threat model when compared to all the other bugs and vulnerabilities that > might be present (or not) on example.com when we interact with it. I'm no= t > saying its not our problem, I'm just saying it is more or less par for le= vel > of vulnerability we already have by connecting to that host. Yeah, I don't agree. People like to complain about open redirectors, but the reality is that the vast majority of non-trivial web sites contain them and don't feel a need to close them. The situation is quite unlike XSS, which sites actively worry about and repair. > There are auth patterns using redirect that I think would be useful to > support. The websockets API wont be able to pass the redir info to the JS= on > failure so we can't just bump the issue out. Plus I think having a full > fledged http bootstrap without caveat and exception is a good thing from = a > modeling point of view for a lot of the same reasons I think masking the > whole client->server request stream is a better model. That's all fine and good, but we don't need to address those use cases in the first iteration of the protocol. If these turn out to be pressing issues that can't be addressed satisfactory at the application layer, then we can revisit this question. Anything else is premature. I also don't buy your argument about simplifying the model by increasing complexity. Adding complexity does not improve security. Adam From ibc@aliax.net Mon Mar 28 16:15:20 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4A93A679F for ; Mon, 28 Mar 2011 16:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KK7dcLdMpkYM for ; Mon, 28 Mar 2011 16:15:19 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 627643A6960 for ; Mon, 28 Mar 2011 16:15:19 -0700 (PDT) Received: by qyk29 with SMTP id 29so1497135qyk.10 for ; Mon, 28 Mar 2011 16:16:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.122.81 with SMTP id k17mr3895817qcr.239.1301354216680; Mon, 28 Mar 2011 16:16:56 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Mon, 28 Mar 2011 16:16:56 -0700 (PDT) In-Reply-To: References: <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com> Date: Tue, 29 Mar 2011 01:16:56 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Greg Wilkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Thomson, Martin" , Hybi Subject: Re: [hybi] DNS SRV for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 23:15:20 -0000 2011/3/28 Greg Wilkins : > So there is not much we can do to tell clients that they should use > SRV when creating the HTTP connection. > > So why doesn't HTTP use it? Maybe just because SRV appeared later then HTTP. Anyhow, is it not enough to say that widely implemented protocols as SIP and XMPP make extensive usage of SRV records? Innovation is not always carried over HTTP ;) --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Mar 28 16:20:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DFB63A6A74 for ; Mon, 28 Mar 2011 16:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wnTCKl3geIX for ; Mon, 28 Mar 2011 16:20:57 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 927473A6960 for ; Mon, 28 Mar 2011 16:20:57 -0700 (PDT) Received: by qyk29 with SMTP id 29so1499279qyk.10 for ; Mon, 28 Mar 2011 16:22:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.122.81 with SMTP id k17mr3898785qcr.239.1301354554807; Mon, 28 Mar 2011 16:22:34 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Mon, 28 Mar 2011 16:22:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Mar 2011 01:22:34 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Adam Barth Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org, Patrick McManus Subject: Re: [hybi] Why redirects are a bad for the security of WebSockets (was Re: Clarify wheter HTTP responses other than 101 are valid) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 23:20:59 -0000 2011/3/28 Adam Barth : > Reading this code, it's quite natural to assume that sending and > receiving information on socket will actually communicate with > example.com. =C2=A0For example, I might send confidential information to > example.com or rely upon the integrity of information received from > example.com. =C2=A0However, if example.com has has an open redirector (as > is extremely common on the Internet), this assumption is incorrect and > leads to vulnerabilities. Let me a question: if you would trust the connection with example.com, why shouldn't you trust it in case it redirects you to other place? > Now, we can wring our hands and claim that this sort of issue isn't > our problem, but it is. =C2=A0Simply warning folks about these traps in > Security Considerations is just passing the buck. =C2=A0Instead, we > shouldn't add this complexity to WebSockets at this time. =C2=A0We can > always change out minds and add support for redirects in the future, > but we can never remove support once added. Which is the main advantage/feature HTTP redirections provide? is it load-balancing? If so, forget the ugly 3XX responses and just add DNS SRV support to WebSocket protocol. --=20 I=C3=B1aki Baz Castillo From ietf@adambarth.com Mon Mar 28 16:33:30 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93DFE3A6AA1 for ; Mon, 28 Mar 2011 16:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgSvBmKykBXP for ; Mon, 28 Mar 2011 16:33:29 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 80FBA3A6A9F for ; Mon, 28 Mar 2011 16:33:29 -0700 (PDT) Received: by yic13 with SMTP id 13so1569633yic.31 for ; Mon, 28 Mar 2011 16:35:07 -0700 (PDT) Received: by 10.150.250.3 with SMTP id x3mr4763001ybh.333.1301355305774; Mon, 28 Mar 2011 16:35:05 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id p23sm1594254ybk.9.2011.03.28.16.35.04 (version=SSLv3 cipher=OTHER); Mon, 28 Mar 2011 16:35:05 -0700 (PDT) Received: by iwn39 with SMTP id 39so4168353iwn.31 for ; Mon, 28 Mar 2011 16:35:04 -0700 (PDT) Received: by 10.43.55.84 with SMTP id vx20mr7155211icb.49.1301355304097; Mon, 28 Mar 2011 16:35:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.133.200 with HTTP; Mon, 28 Mar 2011 16:34:34 -0700 (PDT) In-Reply-To: References: From: Adam Barth Date: Mon, 28 Mar 2011 16:34:34 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org, Patrick McManus Subject: Re: [hybi] Why redirects are a bad for the security of WebSockets (was Re: Clarify wheter HTTP responses other than 101 are valid) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 23:33:30 -0000 On Mon, Mar 28, 2011 at 4:22 PM, I=F1aki Baz Castillo wrote= : > 2011/3/28 Adam Barth : >> Reading this code, it's quite natural to assume that sending and >> receiving information on socket will actually communicate with >> example.com. =A0For example, I might send confidential information to >> example.com or rely upon the integrity of information received from >> example.com. =A0However, if example.com has has an open redirector (as >> is extremely common on the Internet), this assumption is incorrect and >> leads to vulnerabilities. > > Let me a question: if you would trust the connection with example.com, > why shouldn't you trust it in case it redirects you to other place? As stated above, we're assuming example.com has an open redirector. Adam From ibc@aliax.net Mon Mar 28 16:42:00 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 430113A6A8B for ; Mon, 28 Mar 2011 16:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuTpTgS9fSaY for ; Mon, 28 Mar 2011 16:41:59 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 505783A6980 for ; Mon, 28 Mar 2011 16:41:59 -0700 (PDT) Received: by qyk29 with SMTP id 29so1506726qyk.10 for ; Mon, 28 Mar 2011 16:43:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.122.81 with SMTP id k17mr3910039qcr.239.1301355816882; Mon, 28 Mar 2011 16:43:36 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Mon, 28 Mar 2011 16:43:36 -0700 (PDT) In-Reply-To: <4D907CC6.7080707@isode.com> References: <4D907CC6.7080707@isode.com> Date: Tue, 29 Mar 2011 01:43:36 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Review of draft-ietf-hybi-thewebsocketprotocol-06.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 23:42:00 -0000 2011/3/28 Alexey Melnikov : > =C2=A0These subprotocol names do not need to be registered, but if a > > I question the wisdom of not having standard subprotocols registered. > Defining an IANA registry with a liberal registration policy (e.g. "First > Come First Served") is easy. Note that HTTP world is like a jungle in which each web application defines its own features and mechanisms. Web developers don't read RFC's, most of them don't know neither HTTP protocol. Instead they are used to create their own logic and provide both the client code (HTML/JavaScript) and the server code (PHP or any language), without dealing with HTTP. So I don't expect that web developers would look first for an official registry of WebSocket subprotocols. Just my opinion. --=20 I=C3=B1aki Baz Castillo From theturtle32@gmail.com Mon Mar 28 16:57:57 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B1633A6A8B for ; Mon, 28 Mar 2011 16:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.966 X-Spam-Level: X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLmJoT-TS4K1 for ; Mon, 28 Mar 2011 16:57:55 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CAB413A6A90 for ; Mon, 28 Mar 2011 16:57:55 -0700 (PDT) Received: by iwn39 with SMTP id 39so4187789iwn.31 for ; Mon, 28 Mar 2011 16:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YFqAYqJGzyKDTExbXLcPvUjSVaLzBvMjk7M0kE3vBAQ=; b=vipNWVg4fcVkPdnb9TLQdPYnC4AT/tyTRNZTNGjW2fjs0rB2j5ae9Ne2fAmZOAPMaq EfqskXckY+q3Kx9X0GwHS2T8tsKezgr4emlm9C3sbme/D2mbTAHEPjLe4cIJkZPEs6ro vCbEbsw+40KEWk5KdeXWnGIuWPFmDt31kKMB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=n7CTYl9mth0j8yOolBq5hyC5kaOeHZtk7GC5bStJV5s1ZIyWvDX0+orwVvQldnaxEe OmJZwgKDiIczIBuVfMNrmrjYXk30DLLmViI6cIs3jd8pSP95nxyIs7d0oSRfiKvaLg1J OJJTuHaMZ1hYv8Vejt6CC8DB1GghfqL4806ik= MIME-Version: 1.0 Received: by 10.231.117.93 with SMTP id p29mr4835666ibq.126.1301356773461; Mon, 28 Mar 2011 16:59:33 -0700 (PDT) Received: by 10.231.168.202 with HTTP; Mon, 28 Mar 2011 16:59:33 -0700 (PDT) In-Reply-To: References: <4D907CC6.7080707@isode.com> Date: Mon, 28 Mar 2011 16:59:33 -0700 Message-ID: From: Brian To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Review of draft-ietf-hybi-thewebsocketprotocol-06.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 23:57:57 -0000 Honestly, I doubt subprotocols will be used commonly at all. The subprotocol is going to be by-and-large specific to every individual web app. It could be useful for libraries like Socket.IO (https://github.com/learnboost/Socket.IO) that abstract and extend the protocol... but I think most of the time the resource will end up serving the purpose envisioned for the subprotocols. I know I have pretty much no intention of using an explicit subprotocol in my application development. Brian On Mon, Mar 28, 2011 at 4:43 PM, I=F1aki Baz Castillo wrote= : > 2011/3/28 Alexey Melnikov : >> =A0These subprotocol names do not need to be registered, but if a >> >> I question the wisdom of not having standard subprotocols registered. >> Defining an IANA registry with a liberal registration policy (e.g. "Firs= t >> Come First Served") is easy. > > Note that HTTP world is like a jungle in which each web application > defines its own features and mechanisms. Web developers don't read > RFC's, most of them don't know neither HTTP protocol. Instead they are > used to create their own logic and provide both the client code > (HTML/JavaScript) and the server code (PHP or any language), without > dealing with HTTP. > > So I don't expect that web developers would look first for an official > registry of WebSocket subprotocols. Just my opinion. > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From phil127@gmail.com Mon Mar 28 17:33:01 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46E583A6A97 for ; Mon, 28 Mar 2011 17:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buRRoZZruwSq for ; Mon, 28 Mar 2011 17:32:59 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 379433A6A90 for ; Mon, 28 Mar 2011 17:32:59 -0700 (PDT) Received: by wwa36 with SMTP id 36so3209753wwa.13 for ; Mon, 28 Mar 2011 17:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=l+i1iKyRY5/5w8Nnkq/lwQzacqOO0+Lzc4t0ya7+z5A=; b=R0cKCBrr5bLWqaEsWdZs1iB0o9e38C9CtIQVIMQTjxp+YhCc6jtMOenTPEoZVLQ6Fx 4yguxVdhrUb8i+RM3wEEdRiNx+IiYRgeRATb6/mnp9rqEcPLDplGIpo47n8QHD5LhJe2 MxyPlUQTTM3RRc0r1PzCJhyBTNI+dsqjbkpoA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ICrVxDSJ/kSMcwEMd0TCzcOrhogLJDysv7lfoUu+i4GIjVy8Znma727HivIfy+zLbW vBo0UXw+d5dyOm+whSZB0ZDEM4x9v93Q0Ufaw8wP+PelAFdB04Jr3F+k28nTvXBNW/7r nnYMPVo7aJcfNLFQqzqUhuB6ejp0vBAU7Bohw= Received: by 10.227.150.90 with SMTP id x26mr4519909wbv.17.1301358875980; Mon, 28 Mar 2011 17:34:35 -0700 (PDT) Received: from [212.201.72.254] (pptp-212-201-72-254.pptp.stw-bonn.de [212.201.72.254]) by mx.google.com with ESMTPS id y12sm2249473wby.8.2011.03.28.17.34.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2011 17:34:34 -0700 (PDT) Message-ID: <4D9128E6.50509@gmail.com> Date: Tue, 29 Mar 2011 02:33:42 +0200 From: Philipp Serafin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian References: <4D907CC6.7080707@isode.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org Subject: Re: [hybi] Review of draft-ietf-hybi-thewebsocketprotocol-06.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 00:33:01 -0000 I believe the situation is very similar to the one of HTTP. The majority of, e.g. HTTP POST requests don't follow any other semantics than of those defined by the resource they are POSTing to. However, there have come up a number of protocols recently that are layered on top of HTTP - oAuth, OpenID, the whole SOAP ecosystem (not so recently). Except, that in HTTP, there is not really a clean way to tell that the response is actually part of, say, an OpenID exchange. Sub protocols could fill that gap in WS. They can also be useful if public APIs and libraries can be used together. For example, there may be libraries that provide an IMAP style query/response/notification structure on top of WS. There may be multiple different libraries like that that may become popular. A public API could then choose to support more than one of them and use the sub protocols to switch between the different libraries. I agree, though, that the majority of uses will probably purely internal and won't make use of sub protocols. I don't think this is less semantically clear, though - if a WS connection without a sub protocol is established, the semantics of the connection are essentially defined by the resource being connected to. I think requiring IANA registration would be a major hindrance for this feature. Even if the registration policy is liberal, this would still be another organisation developers would have to work with. And I think, especially developers of small libraries would rather opt not to use a sub protocol at all in this case instead of going through the trouble of a registration. Prefixing a protocol name with a domain seems like a more intuitive and accessible approach to me and solves the name collision problem just as well. Philipp Serafin On 29.03.2011 01:59, Brian wrote: > Honestly, I doubt subprotocols will be used commonly at all. The > subprotocol is going to be by-and-large specific to every individual > web app. It could be useful for libraries like Socket.IO > (https://github.com/learnboost/Socket.IO) that abstract and extend the > protocol... but I think most of the time the resource will end up > serving the purpose envisioned for the subprotocols. I know I have > pretty much no intention of using an explicit subprotocol in my > application development. > > Brian > > On Mon, Mar 28, 2011 at 4:43 PM, Iñaki Baz Castillo wrote: >> 2011/3/28 Alexey Melnikov : >>> These subprotocol names do not need to be registered, but if a >>> >>> I question the wisdom of not having standard subprotocols registered. >>> Defining an IANA registry with a liberal registration policy (e.g. "First >>> Come First Served") is easy. >> Note that HTTP world is like a jungle in which each web application >> defines its own features and mechanisms. Web developers don't read >> RFC's, most of them don't know neither HTTP protocol. Instead they are >> used to create their own logic and provide both the client code >> (HTML/JavaScript) and the server code (PHP or any language), without >> dealing with HTTP. >> >> So I don't expect that web developers would look first for an official >> registry of WebSocket subprotocols. Just my opinion. >> >> >> -- >> Iñaki Baz Castillo >> >> _______________________________________________ >> 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 From mcmanus@ducksong.com Tue Mar 29 00:00:05 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC2D3A6917 for ; Tue, 29 Mar 2011 00:00:05 -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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ma72Oa8KMBLt for ; Tue, 29 Mar 2011 00:00:04 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 6C2653A676A for ; Tue, 29 Mar 2011 00:00:04 -0700 (PDT) Received: from dhcp-15b6.meeting.ietf.org (dhcp-15b6.meeting.ietf.org [130.129.21.182]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 6B7AC10159; Tue, 29 Mar 2011 03:01:41 -0400 (EDT) Message-ID: <4D9183D3.8030201@ducksong.com> Date: Tue, 29 Mar 2011 09:01:39 +0200 From: Patrick McManus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adam Barth References: <4D910DF0.4070204@ducksong.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Why redirects are a bad for the security of WebSockets (was Re: Clarify wheter HTTP responses other than 101 are valid) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:00:05 -0000 > I also don't buy your argument about simplifying the model by > increasing complexity. Adding complexity does not improve security. > Neither of us is arguing for increased complexity - we just have different views on what creates complexity. My argument is that adding restrictions and caveats is what adds the complexity. Vanilla HTTP is well understood and reusing that (Redirects, 401's, and all) as it is normally understood reduces the complexity of the definition. From julian.reschke@gmx.de Tue Mar 29 00:12:32 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81FF3A6886 for ; Tue, 29 Mar 2011 00:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbSn9UYf2dpV for ; Tue, 29 Mar 2011 00:12:30 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id DAE323A683F for ; Tue, 29 Mar 2011 00:12:29 -0700 (PDT) Received: (qmail invoked by alias); 29 Mar 2011 07:14:06 -0000 Received: from dhcp-536f.meeting.ietf.org (EHLO [130.129.83.111]) [130.129.83.111] by mail.gmx.net (mp001) with SMTP; 29 Mar 2011 09:14:06 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+hWI8vNfShKMCl7vCc2f9SeiPKYx78YQotjy2d4g GlbxPfHjbvgT6k Message-ID: <4D9186BB.6060700@gmx.de> Date: Tue, 29 Mar 2011 09:14:03 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Wilkins References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: hybi@ietf.org, Patrick McManus Subject: Re: [hybi] Why redirects are a bad for the security of WebSockets (was Re: Clarify wheter HTTP responses other than 101 are valid) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:12:32 -0000 On 28.03.2011 23:06, Greg Wilkins wrote: > ... > Adam, > > I don't think it is "our problem". I think it is a "W3C/WHATWG > HTML-5 WG problem". > > This is essentially an API issue for the browser websocket object. > There are plenty of ways around this (adding optional follow > redirects, exposing redirect responses etc. etc.), but I think it is > the W3C and WHATWG HTML-5 working groups that should be where such > matters are decided. > ... Absolutely. The problem is automatically following the redirect without notifying the caller. BR, Julian From salvatore.loreto@ericsson.com Tue Mar 29 00:55:25 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B728B3A68E1 for ; Tue, 29 Mar 2011 00:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UFQENDgR08m for ; Tue, 29 Mar 2011 00:55:24 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 682D43A6889 for ; Tue, 29 Mar 2011 00:55:24 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-95-4d9190cdb065 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FD.4F.09202.DC0919D4; Tue, 29 Mar 2011 09:57:01 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 29 Mar 2011 09:57:01 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0876E236E for ; Tue, 29 Mar 2011 10:57:01 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C5AF550AA6 for ; Tue, 29 Mar 2011 10:57:00 +0300 (EEST) Received: from dhcp-1324.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6D67050A9D for ; Tue, 29 Mar 2011 10:57:00 +0300 (EEST) Message-ID: <4D9190CC.70000@ericsson.com> Date: Tue, 29 Mar 2011 09:57:00 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: hybi@ietf.org References: <6.2.5.6.2.20110326231844.0d9d1078@elandnews.com> In-Reply-To: <6.2.5.6.2.20110326231844.0d9d1078@elandnews.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [hybi] IETF 80 HYBI WG session: slides X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:55:25 -0000 Hi there, I have just uploaded the slides for the today meeting: https://datatracker.ietf.org/meeting/80/materials.html -- Salvatore Loreto www.sloreto.com On 3/27/11 8:32 AM, S Moonesamy wrote: > Hello, > > The IETF 80 HYBI WG session will held in the Congress Hall III room > at 1:00 p.m. (CET) on Tuesday March 29, 2011. The agenda has been > posted to http://tools.ietf.org/wg/hybi/agenda?item=agenda80.html > > The audio stream is at http://ietf80streaming.dnsalias.net/ietf/ietf804.m3u > > The Jabber room is xmpp:hybi@jabber.ietf.org > > Regards, > S. Moonesamy > HYBI WG Secretary > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From salvatore.loreto@ericsson.com Tue Mar 29 00:58:30 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3E93A6889 for ; Tue, 29 Mar 2011 00:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbEfYA1UM45X for ; Tue, 29 Mar 2011 00:58:29 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 7CB193A68E1 for ; Tue, 29 Mar 2011 00:58:29 -0700 (PDT) X-AuditID: c1b4fb3d-b7bbbae000005311-b0-4d9191869626 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AC.0D.21265.681919D4; Tue, 29 Mar 2011 10:00:06 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 29 Mar 2011 10:00:06 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 56288236E; Tue, 29 Mar 2011 11:00:06 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1F5F550AA6; Tue, 29 Mar 2011 11:00:06 +0300 (EEST) Received: from dhcp-1324.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B7A9F50A9D; Tue, 29 Mar 2011 11:00:05 +0300 (EEST) Message-ID: <4D919185.9090204@ericsson.com> Date: Tue, 29 Mar 2011 10:00:05 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary="------------070605010205070403060909" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: Simon Pietro Romano Subject: [hybi] meeting info: Meetecho support for HyBi session X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:58:30 -0000 --------------070605010205070403060909 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit A virtual room for remote participation has been reserved on the Meetecho system. Access to the on-line session (including audio and video streams) will be available at: http://meetecho.comics.unina.it/WebLite/login.jsp?ietf=hybi The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://ietf.conf.meetecho.com/ --------------070605010205070403060909 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit 
A virtual room for remote participation has been reserved on the
Meetecho system. Access to the on-line session (including audio and video streams) will be available at:
http://meetecho.comics.unina.it/WebLite/login.jsp?ietf=hybi

The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have
an integrated experience involving all media and allowing you to interact with the room.

A tutorial of interactivity features of the tool can be found at:
http://ietf.conf.meetecho.com/


  


--------------070605010205070403060909--

From fielding@gbiv.com  Tue Mar 29 01:04:26 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD203A6AC8 for ; Tue, 29 Mar 2011 01:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQR-YMZVbBK3 for ; Tue, 29 Mar 2011 01:04:25 -0700 (PDT)
Received: from homiemail-a64.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id 33BB73A6A83 for ; Tue, 29 Mar 2011 01:04:25 -0700 (PDT)
Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id A30C743807F; Tue, 29 Mar 2011 01:06:02 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=sWuuvIqcL8SwJPf8 /JYvk0bZ1iXXLOA1ZgvXpJn84d+ccp41hRa3ZRef794YQS1Awc541/ZZwGibL818 DFhDGvvsZp9EMqidT0AAkqx8JlceOJEbNvv1szRihgVORSXiswmQn5YYSBN1Yxci RNqynQ/idR3Jm3rYbClbsCnxJzg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=6douSKx5/ub5QtrjQG4JTLM9g9Q=; b=KnbbzdqgAik/OUTS+OQxE/qXoToT WPObT5L1TCkDmEA0WGyun7Q8R8BUSqE4ISWAGD3uUiSl/oc3MvChOFAHbwe77E1C n/e2SNqa6jGob5Yw+ov+CuNtb4gRbtRlZvoBfZFoK/CTUqJU+eaiKSa994vS9NR3 XSB8o4KuSuU9nQ4=
Received: from dhcp-13fd.meeting.ietf.org (dhcp-13fd.meeting.ietf.org [130.129.19.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id C51F643807E;  Tue, 29 Mar 2011 01:06:01 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: "Roy T. Fielding" 
In-Reply-To: <4126.1301345621.644965@puncture>
Date: Tue, 29 Mar 2011 10:06:00 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com>   <4126.1301345621.644965@puncture>
To: Dave Cridland 
X-Mailer: Apple Mail (2.1084)
Cc: Server-Initiated HTTP 
Subject: Re: [hybi] DNS SRV for WebSocket
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 08:04:26 -0000

On Mar 28, 2011, at 10:53 PM, Dave Cridland wrote:
> On Mon Mar 28 21:39:46 2011, Greg Wilkins wrote:
>> On 28 March 2011 19:34, I=F1aki Baz Castillo  wrote:
>> > Also, I've explained that SRV is not just for "provide name-based
>> > discovery for a service". SRV provides *Real* load-balancing and
>> > failover. This doesn't exist in HTTP (in which just a hack is used: =
a
>> > DNS A record with different IP's).

There are many ways to do load balancing -- DNS is just one.

>> So the problem using SRV for ws is that ws starts with a HTTP =
connection,
>> which may be existing and may be used for other HTTP requests if the
>> handshake fails.
> Right. Adam's going to hate me, but this would be a perfect use-case =
for a redirect.

Indeed.

> But in any case, we can say that this is a MUST NOT. I appreciate this =
is somewhat bending the rules of HTTP compatibility, but I think it's =
worthwhile for the benefits that SRV records give.

No, it isn't.  SRV has a benefit when there is one authority within
the domain and that authority has control over DNS.  Historically,
that has not been the case for HTTP.  Web servers are not like email,
xmpp, or sip.  They are very direct and anti-establishment.

Is websockets? I don't know. I would find it strange to require
both the same-origin model and SRV, but I guess WS won't be using
same-origin requirements.

>> So there is not much we can do to tell clients that they should use
>> SRV when creating the HTTP connection.
>> So why doesn't HTTP use it?
>=20
> HTTP doesn't use it primarily because it was a concept not familiar to =
the designers of HTTP when it was created, and by the time the idea was =
put forward it was too late to change, since people had deployed web =
services on their domain roots (ie, cridland.net as well as =
www.cridland.net), and therefore there was no utility in a fallback to =
A.

SRV was developed after HTTP and did not see any real deployment
until well after 2616 was done.  In any case, it would not have been
used by HTTP because a goal of web interaction is to have all of the
instruction provided to the client up-front in order to minimize =
latency.
DNS load balancing is only minimally effective because the client has
no choice but to make an initial DNS request (to be cached for the
remainder of its uptime).

> (SRV records themselves were first specified in RFC 2052, back in =
1996, but the mechanism is a generalization of MX records, of course. Of =
some note is that the arguments being raised against SRV records here =
are also all applicable to MX records, which have been deployed =
successfully since the early 90's, and probably before).

Exactly, but email management is inherently centralized because of
the authentication.  Likewise for XMPP and SIP.  And none of those
are sensitive to per-interaction latency during the authentication =
phase.

Any service that relies on some form of centralized administration
is a good match with SRV if and only if the service lookup is faster
than the application requirements for user-perceived latency. The long
tail of HTTP sites is not of that type.  Only a very few websites
would gain any advantage from SRV, and those sites are already using
CDNs and IP-based load balancing to do the same thing without any need
for SRV.

....Roy=

From ibc@aliax.net  Tue Mar 29 01:38:23 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927373A692D for ; Tue, 29 Mar 2011 01:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level: 
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.044,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xl43HV4YhZcV for ; Tue, 29 Mar 2011 01:38:22 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id C32E73A68C7 for ; Tue, 29 Mar 2011 01:38:15 -0700 (PDT)
Received: by qyk29 with SMTP id 29so1695722qyk.10 for ; Tue, 29 Mar 2011 01:39:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.75.196 with SMTP id z4mr4211281qcj.277.1301387993449; Tue, 29 Mar 2011 01:39:53 -0700 (PDT)
Received: by 10.229.35.72 with HTTP; Tue, 29 Mar 2011 01:39:53 -0700 (PDT)
In-Reply-To: 
References:  <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com>   <4126.1301345621.644965@puncture> 
Date: Tue, 29 Mar 2011 10:39:53 +0200
Message-ID: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
To: "Roy T. Fielding" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Server-Initiated HTTP 
Subject: Re: [hybi] DNS SRV for WebSocket
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 08:38:23 -0000

2011/3/29 Roy T. Fielding :
> There are many ways to do load balancing -- DNS is just one.

So cheeaper as DNS SRV? based on a standard as DNS SRV?


>>> So the problem using SRV for ws is that ws starts with a HTTP connectio=
n,
>>> which may be existing and may be used for other HTTP requests if the
>>> handshake fails.
>> Right. Adam's going to hate me, but this would be a perfect use-case for=
 a redirect.
>
> Indeed.

Does a 3XX redirect provide failover? No, it can provide just load-balancin=
g.


>> But in any case, we can say that this is a MUST NOT. I appreciate this i=
s somewhat bending the rules of HTTP compatibility, but I think it's worthw=
hile for the benefits that SRV records give.
>
> No, it isn't. =C2=A0SRV has a benefit when there is one authority within
> the domain and that authority has control over DNS.

Sorry, but in most of the web deployments the author of the web site
also owns the domain so he is free to configure SRV records if he
wants. I can't see the problem.



> =C2=A0Historically,
> that has not been the case for HTTP. =C2=A0Web servers are not like email=
,
> xmpp, or sip. =C2=A0They are very direct and anti-establishment.

If HTTP requires a new TCP connection for each request (or the exotic
and limited pipelined-mode of HTTP/1.1) then this is a limitation in
HTTP protocol (the same doesn't occur in other protocol better
designed as SIP-TCP or XMPP). Anyhow, the client must not perform a
SRV query for each connection, but just one at the beginning (to
resolve the domain).

But WebSocket is a new protocol, is not? In fact, the client
establishes an unique TCP connection with the WS socket, just one.



> SRV was developed after HTTP and did not see any real deployment
> until well after 2616 was done. =C2=A0In any case, it would not have been
> used by HTTP because a goal of web interaction is to have all of the
> instruction provided to the client up-front in order to minimize latency.

Again, the SRV query would be performed just *once*. That cannot
introcude noticeable latency.


> DNS load balancing is only minimally effective because the client has
> no choice but to make an initial DNS request (to be cached for the
> remainder of its uptime).

And what is the problem? why do you say "is only minimally effective"?
The client performs the SRV query at the beginning and internally
stores the result set. If a connection fails it then uses the next
rcached result to try the connection.


> Exactly, but email management is inherently centralized because of
> the authentication. =C2=A0Likewise for XMPP and SIP. =C2=A0And none of th=
ose
> are sensitive to per-interaction latency during the authentication phase.

SIP is not sensitive to per-interaction latency?


> Any service that relies on some form of centralized administration
> is a good match with SRV if and only if the service lookup is faster
> than the application requirements for user-perceived latency. The long
> tail of HTTP sites is not of that type. =C2=A0Only a very few websites
> would gain any advantage from SRV, and those sites are already using
> CDNs and IP-based load balancing to do the same thing without any need
> for SRV.

As I've explained and detailed various times in this thread, the web
adminitrator could decide to use *OR NOT* DNS SRV records for the
ws:// uri. He could still set an IP (ws://1.2.3.4:80) so the client
shouldn't perform a SRV query. Or he could set a domain with no SRV
record (but just A).

So, what is the problem? SRV would be a perfect choice for many people
but you want to prohibit it just because it would be not so useful for
other people (even if they can just ignore and not use it in their
deployments). It would be fully optional from the admin and user
perspective. The website owner could decide to use SRV or not. The
only requeriment, of course, os that WS clients support it (and WS
clients are built in the web browsers, so that shoud not be a
problem).



--=20
I=C3=B1aki Baz Castillo


From pmcmanus@mozilla.com  Tue Mar 29 02:19:20 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34CA3A6947 for ; Tue, 29 Mar 2011 02:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.533
X-Spam-Level: 
X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA3ohj-xNHUu for ; Tue, 29 Mar 2011 02:19:20 -0700 (PDT)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 09B943A687A for ; Tue, 29 Mar 2011 02:19:20 -0700 (PDT)
Received: from dhcp-15b6.meeting.ietf.org (dhcp-15b6.meeting.ietf.org [130.129.21.182]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id E75A910159 for ; Tue, 29 Mar 2011 05:20:57 -0400 (EDT)
Message-ID: <4D91A478.9030905@mozilla.com>
Date: Tue, 29 Mar 2011 11:20:56 +0200
From: Patrick McManus 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: hybi@ietf.org
References: 	<8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com>			<4126.1301345621.644965@puncture>	 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [hybi] DNS SRV for WebSocket
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 09:19:21 -0000

On 3/29/11 10:39 AM, Iñaki Baz Castillo wrote:
>
> But WebSocket is a new protocol, is not? In fact, the client
> establishes an unique TCP connection with the WS socket, just one.
>
Websockets is a new protocol that bootstraps itself off of an HTTP 
transaction. Websockets does not define opening of TCP connections - 
that is HTTP's business. In fact, performing the upgrade of http->ws can 
be done off an idle persistent connection which saves a RTT. Indeed, it 
is very likely if the ws://host is the same as the base page holding the 
javascript that such an optimization will be available. That's a good thing.

If we would like to ignore HTTP and define different semantics for these 
things, then that is fine but ONLY if we want to give up the use of the 
one true port. I don't think that's worth it and it would be a complete 
reboot of the group.





From fielding@gbiv.com  Tue Mar 29 02:20:57 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4480A28C138 for ; Tue, 29 Mar 2011 02:20:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level: 
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrVwFGI3PZpV for ; Tue, 29 Mar 2011 02:20:55 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by core3.amsl.com (Postfix) with ESMTP id 7516128C136 for ; Tue, 29 Mar 2011 02:20:55 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 948DB59405E; Tue, 29 Mar 2011 02:22:33 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=MCX0LcziKipyl2ZJ l9lLQLSmOjXUL1C3lp5XWQjBgIJC3Zsu0a9vuxbWzURrvrzN2kugKUSaer8k3KPF FMMclPTYUUPlSSRD3Z53fZrGenAnbNJOFGYbWzgMshBTpETlshd4fb46Ttt1LtC9 cvsVfMhHKlQE66PpVjlCXME7+T0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=FylsSPkQpl8c431hx3IdxA584NM=; b=cHwRAF2idNwcirlu5LpepzPXZGx4 8cV2W2/hI84oj/OUAXvBWWRB8ENjTumSaoJlCpoV1lMtAS2VCstisZN2n9syMzna WYZmTlg7v4I6pBStGOV+FFGZl6ZSqY43oZqHeRgUZ0Au0jd2d4SFr1ig0IGA39Co CSzGzT3mwDjnnCU=
Received: from dhcp-13fd.meeting.ietf.org (dhcp-13fd.meeting.ietf.org [130.129.19.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 66C26594059;  Tue, 29 Mar 2011 02:22:32 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: "Roy T. Fielding" 
In-Reply-To: 
Date: Tue, 29 Mar 2011 11:22:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2642A59F-EEA1-402E-ABB1-28ECB48C62FD@gbiv.com>
References:  <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com>   <4126.1301345621.644965@puncture>  
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
X-Mailer: Apple Mail (2.1084)
Cc: Server-Initiated HTTP 
Subject: Re: [hybi] DNS SRV for WebSocket
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 09:20:57 -0000

On Mar 29, 2011, at 10:39 AM, I=F1aki Baz Castillo wrote:

> 2011/3/29 Roy T. Fielding :
>> There are many ways to do load balancing -- DNS is just one.
>=20
> So cheeaper as DNS SRV? based on a standard as DNS SRV?

Yes, both cheaper (no added latency) and based on standards (TCP/IP).

>>>> So the problem using SRV for ws is that ws starts with a HTTP =
connection,
>>>> which may be existing and may be used for other HTTP requests if =
the
>>>> handshake fails.
>>> Right. Adam's going to hate me, but this would be a perfect use-case =
for a redirect.
>>=20
>> Indeed.
>=20
> Does a 3XX redirect provide failover? No, it can provide just =
load-balancing.

It is just an identifier -- it provides whatever is identified.

> But in any case, we can say that this is a MUST NOT. I appreciate this =
is somewhat bending the rules of HTTP compatibility, but I think it's =
worthwhile for the benefits that SRV records give.
>>=20
>> No, it isn't.  SRV has a benefit when there is one authority within
>> the domain and that authority has control over DNS.
>=20
> Sorry, but in most of the web deployments the author of the web site
> also owns the domain so he is free to configure SRV records if he
> wants. I can't see the problem.

That is just factually wrong, so there is no point in discussing it.

>>  Historically,
>> that has not been the case for HTTP.  Web servers are not like email,
>> xmpp, or sip.  They are very direct and anti-establishment.
>=20
> If HTTP requires a new TCP connection for each request (or the exotic
> and limited pipelined-mode of HTTP/1.1) then this is a limitation in
> HTTP protocol (the same doesn't occur in other protocol better
> designed as SIP-TCP or XMPP). Anyhow, the client must not perform a
> SRV query for each connection, but just one at the beginning (to
> resolve the domain).

Er, no.  They are very direct as in anyone can mint an identifier and
install their own web server, even if they don't know the domain owner.
They just need to be able to run a process on the host.  That is a good
thing, and it would be foolish to assume otherwise.

> But WebSocket is a new protocol, is not? In fact, the client
> establishes an unique TCP connection with the WS socket, just one.

Yes, it has nothing to do with why SRV is not used by HTTP.  I was
just answering that question, not stating a requirement for websockets.

>> SRV was developed after HTTP and did not see any real deployment
>> until well after 2616 was done.  In any case, it would not have been
>> used by HTTP because a goal of web interaction is to have all of the
>> instruction provided to the client up-front in order to minimize =
latency.
>=20
> Again, the SRV query would be performed just *once*. That cannot
> introcude noticeable latency.

I suggest you open a protocol analyzer and see for yourself.  Keep in
mind that the browser is not going to have SRV records stored from its
prior query on DNS, so it will have to do a new one.

>> DNS load balancing is only minimally effective because the client has
>> no choice but to make an initial DNS request (to be cached for the
>> remainder of its uptime).
>=20
> And what is the problem? why do you say "is only minimally effective"?

Because it is the truth.  DNS round robin or CDN-style geographic
rotation is only minimally effective at load-balancing because the
client stores the result for a long time.  IP-based redirecting is
a far more effective solution for load balancing.  In practice,
both are used for very high volume sites.

> The client performs the SRV query at the beginning and internally
> stores the result set. If a connection fails it then uses the next
> rcached result to try the connection.

Failover and load balancing are not the same things, and DNS A
records come in result sets too.

> Exactly, but email management is inherently centralized because of
>> the authentication.  Likewise for XMPP and SIP.  And none of those
>> are sensitive to per-interaction latency during the authentication =
phase.
>=20
> SIP is not sensitive to per-interaction latency?

Not in the same order of magnitude as HTTP.

> Any service that relies on some form of centralized administration
>> is a good match with SRV if and only if the service lookup is faster
>> than the application requirements for user-perceived latency. The =
long
>> tail of HTTP sites is not of that type.  Only a very few websites
>> would gain any advantage from SRV, and those sites are already using
>> CDNs and IP-based load balancing to do the same thing without any =
need
>> for SRV.
>=20
> As I've explained and detailed various times in this thread, the web
> adminitrator could decide to use *OR NOT* DNS SRV records for the
> ws:// uri. He could still set an IP (ws://1.2.3.4:80) so the client
> shouldn't perform a SRV query. Or he could set a domain with no SRV
> record (but just A).
>=20
> So, what is the problem? SRV would be a perfect choice for many people
> but you want to prohibit it just because it would be not so useful for
> other people (even if they can just ignore and not use it in their
> deployments). It would be fully optional from the admin and user
> perspective. The website owner could decide to use SRV or not. The
> only requeriment, of course, os that WS clients support it (and WS
> clients are built in the web browsers, so that shoud not be a
> problem).

I did not say anything about prohibiting SRV with websocket.
I answered some bad assumptions about its lack of use with HTTP,
because I do know those answers.

....Roy=

From ibc@aliax.net  Tue Mar 29 02:44:54 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401E13A68B7 for ; Tue, 29 Mar 2011 02:44:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.634
X-Spam-Level: 
X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EGaeVJa-rRU for ; Tue, 29 Mar 2011 02:44:53 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 285C03A68AB for ; Tue, 29 Mar 2011 02:44:52 -0700 (PDT)
Received: by qyk29 with SMTP id 29so1728933qyk.10 for ; Tue, 29 Mar 2011 02:46:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.63.154 with SMTP id b26mr3032450qci.163.1301391990790; Tue, 29 Mar 2011 02:46:30 -0700 (PDT)
Received: by 10.229.35.72 with HTTP; Tue, 29 Mar 2011 02:46:30 -0700 (PDT)
In-Reply-To: <2642A59F-EEA1-402E-ABB1-28ECB48C62FD@gbiv.com>
References:  <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com>   <4126.1301345621.644965@puncture>   <2642A59F-EEA1-402E-ABB1-28ECB48C62FD@gbiv.com>
Date: Tue, 29 Mar 2011 11:46:30 +0200
Message-ID: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
To: "Roy T. Fielding" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Server-Initiated HTTP 
Subject: Re: [hybi] DNS SRV for WebSocket
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 09:44:54 -0000

2011/3/29 Roy T. Fielding :
>> Does a 3XX redirect provide failover? No, it can provide just load-balan=
cing.
>
> It is just an identifier -- it provides whatever is identified.

If the server having to reply the 3XX is down then it provides *nothing*.



>> If HTTP requires a new TCP connection for each request (or the exotic
>> and limited pipelined-mode of HTTP/1.1) then this is a limitation in
>> HTTP protocol (the same doesn't occur in other protocol better
>> designed as SIP-TCP or XMPP). Anyhow, the client must not perform a
>> SRV query for each connection, but just one at the beginning (to
>> resolve the domain).
>
> Er, no. =C2=A0They are very direct as in anyone can mint an identifier an=
d
> install their own web server, even if they don't know the domain owner.
> They just need to be able to run a process on the host. =C2=A0That is a g=
ood
> thing, and it would be foolish to assume otherwise.

I've already explained that including SRV records for a WS connection
would be fully optional. If the admin doesn't control the domain (just
has a A record available) it just ignores SRV in his application and
provides a WS URI with an IP or domain (wich just DNS A record).





> Keep in
> mind that the browser is not going to have SRV records stored from its
> prior query on DNS,

Why not? perhaps you are describing the behavior of *current* web
browsers? should a future protocol (websocket) be limited by current
technology? If websockets mandates the usage of SRV, browsers
implementing it will improve their efficience by caching DNS results
and so.



>> The client performs the SRV query at the beginning and internally
>> stores the result set. If a connection fails it then uses the next
>> rcached result to try the connection.
>
> Failover and load balancing are not the same things,

Thanks, I do know it. Perhaps you could point where I've missed both
concepts (sure I didn't).

When a client receives the SRV record (containing various entries) it
must choose a entry with better priority.

In case there are more than one entries with same priority then it
chooses one of them based on their weight value (randomly). This, and
ONLY this, is load-balancing.

If the chosen connection fails, the client must choose the next one
(which could have same priority or less priority depending on the
entries). This is failover/redundancy.

SRV provides all of this in an easy way.



> and DNS A records come in result sets too.

And that is a hack as just provides load balancing (a client receiving
N IP's for a domain doesn't try the second one in case the chosen IP
fails to connect). Are you really comparing the DNS A with various
records (which is a hack) with the SRV mechanism (a standarized and
good designed load-balancing/failover mechanism)?


>> As I've explained and detailed various times in this thread, the web
>> adminitrator could decide to use *OR NOT* DNS SRV records for the
>> ws:// uri. He could still set an IP (ws://1.2.3.4:80) so the client
>> shouldn't perform a SRV query. Or he could set a domain with no SRV
>> record (but just A).
>>
>> So, what is the problem? SRV would be a perfect choice for many people
>> but you want to prohibit it just because it would be not so useful for
>> other people (even if they can just ignore and not use it in their
>> deployments). It would be fully optional from the admin and user
>> perspective. The website owner could decide to use SRV or not. The
>> only requeriment, of course, os that WS clients support it (and WS
>> clients are built in the web browsers, so that shoud not be a
>> problem).
>
> I did not say anything about prohibiting SRV with websocket.
> I answered some bad assumptions about its lack of use with HTTP,
> because I do know those answers.

Ok, honestly I don't care the reasons HTTP doesn't use SRV. I'm just
trying to suggest its usage in WebSocket protocol. For now I've heard
no good reasons for disallowing it, just some bad assumptions about
SRV (due the lack of knowledge).


Regards.



--=20
I=C3=B1aki Baz Castillo


From sm@elandsys.com  Tue Mar 29 03:30:19 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1300E28C158 for ; Tue, 29 Mar 2011 03:30:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.564
X-Spam-Level: 
X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPVab4ZcPfUm for ; Tue, 29 Mar 2011 03:30:15 -0700 (PDT)
Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 1EDD528C152 for ; Tue, 29 Mar 2011 03:30:15 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.239.179]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p2TAVcto010536; Tue, 29 Mar 2011 03:31:44 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1301394706; bh=R0/lOVrhIsoa+aQWQxtY0uIoNZc=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=KrioWbQR639ujuIXx/RegtdYpsZtRRDMpyXsNxD7ittV3xEZ95kJYyDLyPNu+/I4m fplZHAMOvieLDtxX/C/GUvEdWf8XYynuDx+ZqFftZ7383B+sez/05GozVYDLKkpXBk b2AC+nvm7RhgA8svLhH5Vtj/OCdki2Fc4DzooV04=
Message-Id: <6.2.5.6.2.20110329031545.0bfd17d0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 29 Mar 2011 03:31:29 -0700
To: Inaki Baz Castillo 
From: S Moonesamy 
In-Reply-To: 
References:  <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com>   <4126.1301345621.644965@puncture>   <2642A59F-EEA1-402E-ABB1-28ECB48C62FD@gbiv.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Joe Hildebrand , Server-Initiated HTTP 
Subject: Re: [hybi] DNS SRV for WebSocket
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 10:30:19 -0000

Hi Inaki,
At 02:46 29-03-2011, Inaki Baz Castillo wrote:
>Ok, honestly I don't care the reasons HTTP doesn't use SRV. I'm just
>trying to suggest its usage in WebSocket protocol. For now I've heard
>no good reasons for disallowing it, just some bad assumptions about
>SRV (due the lack of knowledge).

There were 18 messages posted to this mailing list about this topic 
yesterday.  This working group has a history of long discussions and 
abnormal levels of controversy.  To avoid all that, you could do the following:

  (i)   Propose some text to be inserted in the draft and accompany it
        with arguments for the change; or

  (ii)  Post an I-D as an individual submission; or

  (iii) Raise it as a issue during the WG session that will be held in
        30 minutes.

Regards,
S. Moonesamy
Hybi WG Secretary 


From ibc@aliax.net  Tue Mar 29 03:49:21 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 696C628C138 for ; Tue, 29 Mar 2011 03:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.635
X-Spam-Level: 
X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=0.042,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hjcr6XcsE-A4 for ; Tue, 29 Mar 2011 03:49:20 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 9E3263A693E for ; Tue, 29 Mar 2011 03:49:20 -0700 (PDT)
Received: by qwg5 with SMTP id 5so19133qwg.31 for ; Tue, 29 Mar 2011 03:50:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.75.196 with SMTP id z4mr4295372qcj.277.1301395858400; Tue, 29 Mar 2011 03:50:58 -0700 (PDT)
Received: by 10.229.35.72 with HTTP; Tue, 29 Mar 2011 03:50:58 -0700 (PDT)
In-Reply-To: <6.2.5.6.2.20110329031545.0bfd17d0@resistor.net>
References:  <8B0A9FCBB9832F43971E38010638454F04027B925A@SISPE7MB1.commscope.com>   <4126.1301345621.644965@puncture>   <2642A59F-EEA1-402E-ABB1-28ECB48C62FD@gbiv.com>  <6.2.5.6.2.20110329031545.0bfd17d0@resistor.net>
Date: Tue, 29 Mar 2011 12:50:58 +0200
Message-ID: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
To: S Moonesamy 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Joe Hildebrand , Server-Initiated HTTP 
Subject: Re: [hybi] DNS SRV for WebSocket
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 10:49:21 -0000

2011/3/29 S Moonesamy :
> There were 18 messages posted to this mailing list about this topic
> yesterday. =C2=A0This working group has a history of long discussions and
> abnormal levels of controversy. =C2=A0To avoid all that, you could do the
> following:
>
> =C2=A0(i) =C2=A0 Propose some text to be inserted in the draft and accomp=
any it
> =C2=A0 =C2=A0 =C2=A0 with arguments for the change; or
>
> =C2=A0(ii) =C2=A0Post an I-D as an individual submission; or
>
> =C2=A0(iii) Raise it as a issue during the WG session that will be held i=
n
> =C2=A0 =C2=A0 =C2=A0 30 minutes.

Thanks, I'm already logged into the meeting as user ibc708 (just
available for chat).

--=20
I=C3=B1aki Baz Castillo


From fielding@gbiv.com  Tue Mar 29 05:22:00 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2DD3A68FD for ; Tue, 29 Mar 2011 05:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.369
X-Spam-Level: 
X-Spam-Status: No, score=-103.369 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq8gAmemGKle for ; Tue, 29 Mar 2011 05:21:58 -0700 (PDT)
Received: from homiemail-a73.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 976463A6783 for ; Tue, 29 Mar 2011 05:21:58 -0700 (PDT)
Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id BB7851F0086; Tue, 29 Mar 2011 05:23:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=from:content-type :content-transfer-encoding:subject:date:message-id:cc:to: mime-version; q=dns; s=gbiv.com; b=ouYX97IvkODVs/sdeQy2Cp1bfDvmf hynj4UpbNpa0qEJnTR2pFwmPMK+vokzd6h7PpRhmUll92w8faoHvW0Y+KLuMBoeJ L40YupwXwZUF6THU/OlsCqV2hRa41ibxCu4Xnbhlk86QbqpCDYyGMIvNNJvO86Wa bG/6F0ckKe4ebo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=from :content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; s=gbiv.com; bh=+tN/iFQEbKutodBfu86GYNYcwsc= ; b=bgKBsFe6QYdlpFRcfD3Ux9ZusrKcpzD1TwEhk/iXQcSg1PLBB67aLkC7hjhp tJYC/6ODvLFeMb2J+yRLfobc2aRQSXP8L2uI6mRKIX/zh9Wx7j6QY4l9GWefq8Rl dqPyKkJ4zRg86l/y+JBHQwjHybQI/m5L9CizxcF7aHmGFVc=
Received: from dhcp-13fd.meeting.ietf.org (dhcp-13fd.meeting.ietf.org [130.129.19.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id D032D1F0085;  Tue, 29 Mar 2011 05:23:35 -0700 (PDT)
From: "Roy T. Fielding" 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 29 Mar 2011 14:23:33 +0200
Message-Id: 
To: Server-Initiated HTTP 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: iesg@iesg.org
Subject: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 12:22:00 -0000

I am finding it difficult to participate in hybi in any meaningful
way due to the very poor assumption that websockets traffic should
use the same ports as Web traffic.  Apparently, this "decision" was
made on the basis of hums at an in-person WG meeting and the chairs
believe it to be consensus (and thus quash any discussion that has
apparent consensus due to the extent to which people keep bringing
up old issues).  It might even make some sense, given the name of
this working group.

Unfortunately, it is a fatal error.  The rest of the protocol
discussion is predicated on it, and enormously complex, for the
sole reason of that initial error in design.  More the pity.
It assumes that the network infrastructure that currently
monitors and balances traffic over 80/443 is going to instantly
adapt to TCP-over-HTTP, as opposed to treating it like a denial
of service attack.

Browsers are fully capable of opening up new ports in firewalls
simply by concerted use of open standards.  Many other applications
do so without this painful corruption of existing protocols. Yes,
it takes time (but not as much time as one would think).  Yes,
there will be some companies that forcibly block some ports,
just like there are some companies that forcibly block HTTP
sites like facebook.com.  That is their right.  If the protocol
is safe to use, it will be deployable over time.  If not, then
it shouldn't make the Web situation worse by increasing the
amount of packet filtering at firewalls.

So, I don't think the hybi work is worth continuing.  The rest of
the protocol decisions simply don't matter -- any of the already
deployed proprietary hacks are better by default because they
are no worse than hybi and don't have the imprimatur of the IETF.
I'd rather develop a protocol that works with network administration
rather than against it.

I only ask that an IESG note be added to the final specification
to the effect that this protocol knowingly misuses the Internet
for the sake of bypassing organizational security.  Be honest and
let the admins make their own decisions.


Cheers,

Roy T. Fielding                     

From gregw@intalio.com  Tue Mar 29 05:41:08 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27EB63A67DB for ; Tue, 29 Mar 2011 05:41:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.642
X-Spam-Level: 
X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.335,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxDRgiRoGlov for ; Tue, 29 Mar 2011 05:41:07 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id E50BB3A63CA for ; Tue, 29 Mar 2011 05:41:06 -0700 (PDT)
Received: by vws12 with SMTP id 12so93216vws.31 for ; Tue, 29 Mar 2011 05:42:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.18.102 with SMTP id v6mr6413277vdd.224.1301402564171; Tue, 29 Mar 2011 05:42:44 -0700 (PDT)
Received: by 10.52.155.71 with HTTP; Tue, 29 Mar 2011 05:42:44 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 29 Mar 2011 23:42:44 +1100
Message-ID: 
From: Greg Wilkins 
To: "Roy T. Fielding" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Server-Initiated HTTP , iesg@iesg.org
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 12:41:08 -0000

Roy,

Perhaps the argument should be made to http-bis to remove or restrict
usage of upgrade.  Websocket appears to be a valid usage of that
mechanism and intermediaries and firewalls should support it (or are
free to block it).

However, I also agree that we should have developed a protocol that
would work on dedicated ports and just use upgrade as a fallback.

cheers




On 29 March 2011 23:23, Roy T. Fielding  wrote:
> I am finding it difficult to participate in hybi in any meaningful
> way due to the very poor assumption that websockets traffic should
> use the same ports as Web traffic. =A0Apparently, this "decision" was
> made on the basis of hums at an in-person WG meeting and the chairs
> believe it to be consensus (and thus quash any discussion that has
> apparent consensus due to the extent to which people keep bringing
> up old issues). =A0It might even make some sense, given the name of
> this working group.
>
> Unfortunately, it is a fatal error. =A0The rest of the protocol
> discussion is predicated on it, and enormously complex, for the
> sole reason of that initial error in design. =A0More the pity.
> It assumes that the network infrastructure that currently
> monitors and balances traffic over 80/443 is going to instantly
> adapt to TCP-over-HTTP, as opposed to treating it like a denial
> of service attack.
>
> Browsers are fully capable of opening up new ports in firewalls
> simply by concerted use of open standards. =A0Many other applications
> do so without this painful corruption of existing protocols. Yes,
> it takes time (but not as much time as one would think). =A0Yes,
> there will be some companies that forcibly block some ports,
> just like there are some companies that forcibly block HTTP
> sites like facebook.com. =A0That is their right. =A0If the protocol
> is safe to use, it will be deployable over time. =A0If not, then
> it shouldn't make the Web situation worse by increasing the
> amount of packet filtering at firewalls.
>
> So, I don't think the hybi work is worth continuing. =A0The rest of
> the protocol decisions simply don't matter -- any of the already
> deployed proprietary hacks are better by default because they
> are no worse than hybi and don't have the imprimatur of the IETF.
> I'd rather develop a protocol that works with network administration
> rather than against it.
>
> I only ask that an IESG note be added to the final specification
> to the effect that this protocol knowingly misuses the Internet
> for the sake of bypassing organizational security. =A0Be honest and
> let the admins make their own decisions.
>
>
> Cheers,
>
> Roy T. Fielding =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

From jat@google.com  Tue Mar 29 05:46:14 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 237D43A67F0 for ; Tue, 29 Mar 2011 05:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.843
X-Spam-Level: 
X-Spam-Status: No, score=-105.843 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8ehrmUEnf4g for ; Tue, 29 Mar 2011 05:46:13 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 15E373A6783 for ; Tue, 29 Mar 2011 05:46:12 -0700 (PDT)
Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p2TClo4v012263 for ; Tue, 29 Mar 2011 05:47:50 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301402870; bh=28REU6GYGDwP6jur62gWbGYChTM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=SFG/yT8CGClvizZqVorB3+FYYZNLeUF2mbkLnQM4/qb3qtJpvasa9LusaEfx64nal mPT3DVD336M7ro3lOLuaA==
Received: from yxa15 (yxa15.prod.google.com [10.190.1.15]) by hpaq3.eem.corp.google.com with ESMTP id p2TClmOs008075 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 29 Mar 2011 05:47:49 -0700
Received: by yxa15 with SMTP id 15so55120yxa.23 for ; Tue, 29 Mar 2011 05:47:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ViVkJ2aYXrsTBJYuU8dlUe4iqbim/es3+C+gCxdakls=; b=NZoP0XYTm33Ub+Xrsesoh+vqxSUa7ilu7LCWlTgwjVyprOGMTWVdh2u6wPAQb8zFGW ptFfxOfO8QFlAQGnpbwg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=TxBHZSGCzxB1yGi+quTa7JWrCPRNs3dnne4Zz8swEPdOHjsCbl9xGIlBqWcNThEPVx xrl/ZxhkSK9+fW9TMZOw==
Received: by 10.151.87.6 with SMTP id p6mr37550ybl.352.1301402868151; Tue, 29 Mar 2011 05:47:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.200.16 with HTTP; Tue, 29 Mar 2011 05:47:28 -0700 (PDT)
In-Reply-To: 
References:  
From: John Tamplin 
Date: Tue, 29 Mar 2011 08:47:28 -0400
Message-ID: 
To: Greg Wilkins 
Content-Type: multipart/alternative; boundary=000e0cd2da0eaa7750049f9e7754
X-System-Of-Record: true
Cc: "Roy T. Fielding" , Server-Initiated HTTP , iesg@iesg.org
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 12:46:14 -0000

--000e0cd2da0eaa7750049f9e7754
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 29, 2011 at 8:42 AM, Greg Wilkins  wrote:

> However, I also agree that we should have developed a protocol that
> would work on dedicated ports and just use upgrade as a fallback.
>

That option was discussed several times, and there was little support for
doing so.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--000e0cd2da0eaa7750049f9e7754
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Tue, Mar 29, 2011 at 8:42 AM, Greg Wilkins <gregw@intalio.com<=
/a>> wrote:


However, I also agree that we should have developed a protocol that

would work on dedicated ports and just use upgrade as a fallback.

That option was discussed several times, and the=
re was little support for doing so.
=C2=A0
-- 
John=
 A. Tamplin


Software Engineer (GWT), Google


--000e0cd2da0eaa7750049f9e7754--

From dendicott@gmail.com  Tue Mar 29 09:22:27 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453B93A6943 for ; Tue, 29 Mar 2011 09:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.561
X-Spam-Level: 
X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmTEi-xogC-d for ; Tue, 29 Mar 2011 09:22:24 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id E3BCA3A6863 for ; Tue, 29 Mar 2011 09:22:22 -0700 (PDT)
Received: by wyb29 with SMTP id 29so324066wyb.31 for ; Tue, 29 Mar 2011 09:24:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=//S0w61jWjgzDn/zlU7YMe/Ead02kwQKKY0jkUvDbR8=; b=XileRSHFMjGlLjhX9+iGPdx7dEoul8MGPus0pBSl5VSuB9rEUmR4VkFYQQX3yESLg/ KKLCW927/SRA6LxV91iLczgbs8sF+36qPsPY3pC6UwAhNXNZ/kkXBT0jTygPSm+ULWOZ yeFHSDfr3+kRskokCRgn+cVyDOoJZ50rsueNY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Qa+21SuZAqmKVQ8USkIBC0Xfz5s7yj9HceOe68069DRdk+2y+/4vrRV6kgiCLAls/C qSCrtkOLDqlfJem7k7/xuX7PgYSUJxjbRlR+LO5ZFEDI65ACjpLR8gS/JoYjBCkNczFw K13OZJLucbCwf+PnZGGESN1JK47g3ke049hRc=
MIME-Version: 1.0
Received: by 10.216.205.17 with SMTP id i17mr4172419weo.71.1301415840506; Tue, 29 Mar 2011 09:24:00 -0700 (PDT)
Received: by 10.216.153.41 with HTTP; Tue, 29 Mar 2011 09:24:00 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 29 Mar 2011 12:24:00 -0400
Message-ID: 
From: David Endicott 
To: "Roy T. Fielding" 
Content-Type: multipart/alternative; boundary=0016e6de001de0f80c049fa17c8e
Cc: Server-Initiated HTTP , iesg@iesg.org
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 16:22:27 -0000

--0016e6de001de0f80c049fa17c8e
Content-Type: text/plain; charset=ISO-8859-1

Roy,

With all due respect and forgive me if I have some mistaken assumptions, but
I don't think your concerns are really as much of a problem as you believe.

Since one of the primary intended uses of Websockets is in the context of
browser clients & webservers, it would seem to me that allowing the
client-agent to open the conversation via the webserver (via the HTTP
Upgrade) makes perfect sense.  I've been working on integrating Websockets
on the server side both as an independent process and as part of a WSGI
framework and having it involved with the http server environment is, so
far, making good sense - the static content and the dynamic content are
generally related.

You're concern about "tcp-over-http" I believe is also unfounded.  The
connection through firewalls/proxies would have already been negotiated with
the initial HTTP Upgrade request.  That further traffic is not HTTP seems,
to me, irrelevant.  It would be no different than a normal HTTP
request/response with binary payload.   A proxy/firewall that does not
handle HTTP Upgrade properly is not a problem that WebSockets should be
trying to resolve.  The Upgrade mechanism is well defined and standardized
and intermediaries should be able to handle the repercussions.    Since the
connection has already established and continues as an open connection the
traffic is not TCP over HTTP, it's a pre-existing TCP connection that was
originally used for HTTP.   Would you have similar concerns about a simple
TCP connection opened to an arbitrary port by some (non browser) client
agent?  Intermediaries that mis-handle this type of connection are outside
our domain of concern.  While Websockets should take reasonable steps to not
traumatize existing infrastructure, I don't believe using the HTTP Upgrade
mechanism is going to cause widespread chaos.

Further, I resist the idea that ports & protocols should be intimately
bound.  Ports are a property of IP, and are independent of the higher layer
protocols it's carrying.   HTTP can, and regularly is, served on ports other
than 80.   WebSockets can be considered an extension to a HTTP connection
and could very reasonably be assumed that the same server agent that
provides static HTTP documents will also be providing dynamic WebSocket
delivered content.

While certain ports are "well-known" and and reasonably be assumed to be
providing default services/protocols, I do not believe it should
be mandatory or requisite.   HTTP content and WebSocket content is very
often going to be integrated on the client-agent to produce a unified
end-result.   It seems appropriate to me that the server side of that
conversation can be as well.

You mentioned port 443.  That is not HTTP, that is SSL, but it can carry
HTTP.  In a somewhat similar manner Websockets on port 80 isn't HTTP, but it
was brought into existence by it.    I believe protocols should be port
independent, as they have been since the dawn of IP.   Port related user
infrastructure restrictions are outside our domain of concern - that's their
business.

I reserve the right to deploy a WebSockets server process on any port of my
choosing, and in my opinion, having the ability to integrate it into an
existing http server stack is a "good thing".

While I do have a concern (to be addressed elsewhere) about some of the
specifics of the HTTP Upgrade handshake, the basic idea seem to be rational
and sound and follows logically from WebSockets being the asynchronous
content delivery mechanism that parallels the synchronous content delivery
mechanism of HTTP.   The protocols are transport variations operating in a
related content context.

Regards,
       Dave



On Tue, Mar 29, 2011 at 8:23 AM, Roy T. Fielding  wrote:

> I am finding it difficult to participate in hybi in any meaningful
> way due to the very poor assumption that websockets traffic should
> use the same ports as Web traffic.  Apparently, this "decision" was
> made on the basis of hums at an in-person WG meeting and the chairs
> believe it to be consensus (and thus quash any discussion that has
> apparent consensus due to the extent to which people keep bringing
> up old issues).  It might even make some sense, given the name of
> this working group.
>
> Unfortunately, it is a fatal error.  The rest of the protocol
> discussion is predicated on it, and enormously complex, for the
> sole reason of that initial error in design.  More the pity.
> It assumes that the network infrastructure that currently
> monitors and balances traffic over 80/443 is going to instantly
> adapt to TCP-over-HTTP, as opposed to treating it like a denial
> of service attack.
>
> Browsers are fully capable of opening up new ports in firewalls
> simply by concerted use of open standards.  Many other applications
> do so without this painful corruption of existing protocols. Yes,
> it takes time (but not as much time as one would think).  Yes,
> there will be some companies that forcibly block some ports,
> just like there are some companies that forcibly block HTTP
> sites like facebook.com.  That is their right.  If the protocol
> is safe to use, it will be deployable over time.  If not, then
> it shouldn't make the Web situation worse by increasing the
> amount of packet filtering at firewalls.
>
> So, I don't think the hybi work is worth continuing.  The rest of
> the protocol decisions simply don't matter -- any of the already
> deployed proprietary hacks are better by default because they
> are no worse than hybi and don't have the imprimatur of the IETF.
> I'd rather develop a protocol that works with network administration
> rather than against it.
>
> I only ask that an IESG note be added to the final specification
> to the effect that this protocol knowingly misuses the Internet
> for the sake of bypassing organizational security.  Be honest and
> let the admins make their own decisions.
>
>
> Cheers,
>
> Roy T. Fielding                     
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

--0016e6de001de0f80c049fa17c8e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Roy,

With all due respect and forgive me if I have some =
mistaken assumptions, but I don't think your concerns are really as muc=
h of a problem as you believe.

Since one of the pr=
imary intended uses of Websockets is in the context of browser clients &=
; webservers, it would seem to me that allowing the client-agent to open th=
e conversation via the webserver (via the HTTP Upgrade) makes perfect sense=
. =A0I've been working on integrating Websockets on the server side bot=
h as an independent process and as part of a WSGI framework and having it i=
nvolved with the http server=A0environment=A0is, so far, making good sense =
- the static content and the dynamic content are generally related.



You're concern about "tcp-over-http" I be=
lieve is also unfounded. =A0The connection through firewalls/proxies would =
have already been negotiated with the initial HTTP Upgrade request. =A0That=
 further traffic is not HTTP seems, to me, irrelevant. =A0It would be no di=
fferent than a normal HTTP request/response with binary payload. =A0 A prox=
y/firewall that does not handle HTTP Upgrade properly is not a problem that=
 WebSockets should be trying to resolve. =A0The Upgrade mechanism is well d=
efined and standardized and intermediaries should be able to handle the rep=
ercussions. =A0 =A0Since the connection has already established and continu=
es as an open connection the traffic is not TCP over HTTP, it's a pre-e=
xisting TCP connection that was originally used for HTTP. =A0 Would you hav=
e similar concerns about a simple TCP connection opened to an arbitrary por=
t by some (non browser) client agent? =A0Intermediaries that mis-handle thi=
s type of connection are outside our domain of concern. =A0While Websockets=
 should take reasonable steps to not traumatize existing infrastructure, I =
don't believe using the HTTP Upgrade mechanism is going to cause widesp=
read chaos.



Further, I resist the idea that ports & protocols s=
hould be intimately bound. =A0Ports are a property of IP, and are independe=
nt of the higher layer protocols it's carrying. =A0 HTTP can, and regul=
arly is, served on ports other than 80. =A0 WebSockets can be considered an=
 extension to a HTTP connection and could very reasonably be assumed that t=
he same server agent that provides static HTTP documents will also be provi=
ding dynamic WebSocket delivered content.



While certain ports are "well-known" and and =
reasonably be assumed to be providing default services/protocols, I do not =
believe it should be=A0mandatory=A0or requisite. =A0 HTTP content and WebSo=
cket content is very often going to be integrated on the client-agent to pr=
oduce a unified end-result. =A0 It seems appropriate to me that the server =
side of that conversation can be as well.



You mentioned port 443. =A0That is not HTTP, that is SS=
L, but it can carry HTTP. =A0In a somewhat similar manner Websockets on por=
t 80 isn't HTTP, but it was brought into=A0existence=A0by it. =A0 =A0I =
believe protocols should be port independent, as they have been since the d=
awn of IP. =A0 Port related user infrastructure restrictions are outside ou=
r domain of concern - that's their business.



I reserve the right to deploy a WebSockets server proce=
ss on any port of my choosing, and in my opinion, having the ability to int=
egrate it into an existing http server stack is a "good thing".


While I do have a concern (to be addressed elsewhere) a=
bout some of the specifics of the HTTP Upgrade handshake, the basic idea se=
em to be rational and sound and follows logically from WebSockets being the=
 asynchronous content delivery mechanism that parallels the synchronous con=
tent delivery mechanism of HTTP. =A0 The protocols are transport variations=
 operating in a related content context.



Regards,
=A0=A0 =A0 =A0 Dave



On Tue, Mar 29, 2011=
 at 8:23 AM, Roy T. Fielding <fielding@gbiv.com> wrote:


I am finding it difficult to participate in=
 hybi in any meaningful

way due to the very poor assumption that websockets traffic should

use the same ports as Web traffic. =A0Apparently, this "decision"=
 was

made on the basis of hums at an in-person WG meeting and the chairs

believe it to be consensus (and thus quash any discussion that has

apparent consensus due to the extent to which people keep bringing

up old issues). =A0It might even make some sense, given the name of

this working group.



Unfortunately, it is a fatal error. =A0The rest of the protocol

discussion is predicated on it, and enormously complex, for the

sole reason of that initial error in design. =A0More the pity.

It assumes that the network infrastructure that currently

monitors and balances traffic over 80/443 is going to instantly

adapt to TCP-over-HTTP, as opposed to treating it like a denial

of service attack.



Browsers are fully capable of opening up new ports in firewalls

simply by concerted use of open standards. =A0Many other applications

do so without this painful corruption of existing protocols. Yes,

it takes time (but not as much time as one would think). =A0Yes,

there will be some companies that forcibly block some ports,

just like there are some companies that forcibly block HTTP

sites like facebook.com. =A0That is their right. =A0If the protocol

is safe to use, it will be deployable over time. =A0If not, then

it shouldn't make the Web situation worse by increasing the

amount of packet filtering at firewalls.



So, I don't think the hybi work is worth continuing. =A0The rest of

the protocol decisions simply don't matter -- any of the already

deployed proprietary hacks are better by default because they

are no worse than hybi and don't have the imprimatur of the IETF.

I'd rather develop a protocol that works with network administration
rather than against it.



I only ask that an IESG note be added to the final specification

to the effect that this protocol knowingly misuses the Internet

for the sake of bypassing organizational security. =A0Be honest and

let the admins make their own decisions.





Cheers,



Roy T. Fielding =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <http://roy.gbiv.com/>

_______________________________________________

hybi mailing list

hybi@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/hybi





--0016e6de001de0f80c049fa17c8e--

From sm@elandsys.com  Tue Mar 29 11:15:40 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67973A6975 for ; Tue, 29 Mar 2011 11:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.568
X-Spam-Level: 
X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltST7y4l+aAM for ; Tue, 29 Mar 2011 11:15:38 -0700 (PDT)
Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id E5B253A6943 for ; Tue, 29 Mar 2011 11:15:37 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.238.105]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p2TIH3mr004381; Tue, 29 Mar 2011 11:17:10 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1301422633; bh=y/whkcsVarU1E38sUNATcMUm6DI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=MszDJFawU+bll+q6/IyHbuHbDPdNbc0KbacEidXo7kLyLIuUXCaKV/Cg8Z0srWcHs qjHXJrtb18BD9SAlk/ULM+34t8vZrf6EFzd9AcKelA9pccfr5Mm1bboorfEPnJdpnA TSvYY+BxQkwb0Z4egxvwQQRTNgoD+mNdkX2v2pvU=
Message-Id: <6.2.5.6.2.20110329100551.0d86c040@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 29 Mar 2011 10:31:10 -0700
To: Server-Initiated HTTP 
From: S Moonesamy 
In-Reply-To: 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 18:15:40 -0000

Hello,
At 05:23 29-03-2011, Roy T. Fielding wrote:
>I am finding it difficult to participate in hybi in any meaningful
>way due to the very poor assumption that websockets traffic should
>use the same ports as Web traffic.  Apparently, this "decision" was
>made on the basis of hums at an in-person WG meeting and the chairs
>believe it to be consensus (and thus quash any discussion that has

The following should be read as a datapoint.

There was a discussion about ports in October 2009 ( 
http://www.ietf.org/mail-archive/web/hybi/current/msg00709.html 
).  "HTTP compliance" was tracked as ticket #1 ( 
http://trac.tools.ietf.org/wg/hybi/trac/ticket/1 ).  "HTTP 
compliance" is also mentioned in the minutes of the IETF78 HyBi 
Working Group meeting ( 
http://trac.tools.ietf.org/wg/hybi/minutes?item=minutes78.html 
).  There was a formal declaration of consensus on "HTTP compliance" 
in August 2010 ( 
http://www.ietf.org/mail-archive/web/hybi/current/msg02955.html ).

Regards,
S. Moonesamy
Hybi WG Secretary 


From fielding@gbiv.com  Tue Mar 29 11:32:04 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657013A6A82 for ; Tue, 29 Mar 2011 11:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFC+zFu+dQqF for ; Tue, 29 Mar 2011 11:32:02 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id DC4943A6A7F for ; Tue, 29 Mar 2011 11:32:01 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 3A4821B406F; Tue, 29 Mar 2011 11:33:40 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=YKKEW9Eo4wMaLzWg dqBcdqRnCcWv7QAowDY/HvgUZKVgXeE887rQmneZbNpCUyJAiNpGv9zG9IPZxJMT Gz2FJSsN6P3i/P+UTCXORiDvNtjr2sMy6GXszdohoQbwjfjNWyzWTHfKUY502cT9 PZUa/44Pj89FQlB04+dafPdrfu8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=A1zCgFe2Qwgxizx496Mhgpv5w8o=; b=jkbxtPY8RNz+QJO6NH1Fm+H5686P 260QcNUHgpfgPv2HH5kXpBogWlKsFkvIDAo+9og2j8lUnImXHi3FzIMFwsITrXgy Ouv2jpYrZiMCXaTiwu/5e5opJoj79nUlUietIXqwYeMcpdccDXFnIriu7husxjHT C2Yqx6XH/Fmbet8=
Received: from [192.168.222.66] (unknown [109.107.209.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id DA72D1B406B;  Tue, 29 Mar 2011 11:33:38 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Roy T. Fielding" 
In-Reply-To: 
Date: Tue, 29 Mar 2011 20:33:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0FA21125-669C-407F-9A3F-A7BE0F1362AA@gbiv.com>
References:  
To: David Endicott 
X-Mailer: Apple Mail (2.1084)
Cc: Server-Initiated HTTP , iesg@iesg.org
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 18:32:04 -0000

On Mar 29, 2011, at 6:24 PM, David Endicott wrote:

> Roy,
>=20
> With all due respect and forgive me if I have some mistaken =
assumptions, but I don't think your concerns are really as much of a =
problem as you believe.
>=20
> Since one of the primary intended uses of Websockets is in the context =
of browser clients & webservers, it would seem to me that allowing the =
client-agent to open the conversation via the webserver (via the HTTP =
Upgrade) makes perfect sense.  I've been working on integrating =
Websockets on the server side both as an independent process and as part =
of a WSGI framework and having it involved with the http server =
environment is, so far, making good sense - the static content and the =
dynamic content are generally related.

My concern is not about the use of Upgrade.  That, at least, makes
sense once the decision is made to reuse the same connection.

My concern is about the nature of the protocol after the Upgrade
handshake is complete.  WebSockets will not have the same performance
characteristics as the Web.  The connection will stay open a long time,
the messages will be small and occasional in nature, and the TCP
association will persist.  All of those are *good* things if the
surrounding network infrastructure (all the machines that those
bits pass through on their way to the origin server and back) is
prepared for that type of interaction.  If not, then they will be
seen as the equivalent of a denial of service attack.

> You're concern about "tcp-over-http" I believe is also unfounded.  The =
connection through firewalls/proxies would have already been negotiated =
with the initial HTTP Upgrade request.  That further traffic is not HTTP =
seems, to me, irrelevant.  It would be no different than a normal HTTP =
request/response with binary payload.   A proxy/firewall that does not =
handle HTTP Upgrade properly is not a problem that WebSockets should be =
trying to resolve.  The Upgrade mechanism is well defined and =
standardized and intermediaries should be able to handle the =
repercussions.    Since the connection has already established and =
continues as an open connection the traffic is not TCP over HTTP, it's a =
pre-existing TCP connection that was originally used for HTTP.   Would =
you have similar concerns about a simple TCP connection opened to an =
arbitrary port by some (non browser) client agent?  Intermediaries that =
mis-handle this type of connection are outside our domain of concern.  =
While Websockets should take reasonable steps to not traumatize existing =
infrastructure, I don't believe using the HTTP Upgrade mechanism is =
going to cause widespread chaos.

I am not concerned about the HTTP-aware message processors.
They have the ability to decline the Upgrade.  Other forms
of load-balancing routers do not.

> Further, I resist the idea that ports & protocols should be intimately =
bound.  Ports are a property of IP, and are independent of the higher =
layer protocols it's carrying.   HTTP can, and regularly is, served on =
ports other than 80.   WebSockets can be considered an extension to a =
HTTP connection and could very reasonably be assumed that the same =
server agent that provides static HTTP documents will also be providing =
dynamic WebSocket delivered content.
>=20
> While certain ports are "well-known" and and reasonably be assumed to =
be providing default services/protocols, I do not believe it should be =
mandatory or requisite.   HTTP content and WebSocket content is very =
often going to be integrated on the client-agent to produce a unified =
end-result.   It seems appropriate to me that the server side of that =
conversation can be as well.
>=20
> You mentioned port 443.  That is not HTTP, that is SSL, but it can =
carry HTTP.  In a somewhat similar manner Websockets on port 80 isn't =
HTTP, but it was brought into existence by it.    I believe protocols =
should be port independent, as they have been since the dawn of IP.   =
Port related user infrastructure restrictions are outside our domain of =
concern - that's their business.

Nevertheless, your belief does not match deployed network
management products.  We put different architectures on different
standard ports in order to make network admins lives easier.
We don't have to do that for nonstandard ports.

> I reserve the right to deploy a WebSockets server process on any port =
of my choosing, and in my opinion, having the ability to integrate it =
into an existing http server stack is a "good thing".
>=20
> While I do have a concern (to be addressed elsewhere) about some of =
the specifics of the HTTP Upgrade handshake, the basic idea seem to be =
rational and sound and follows logically from WebSockets being the =
asynchronous content delivery mechanism that parallels the synchronous =
content delivery mechanism of HTTP.   The protocols are transport =
variations operating in a related content context.

Umm, they both use TCP.  Good luck keeping those connections open.
HTTP doesn't have asynchronous delivery because that is more
efficiently accomplished via email, IRC, NNTP, or XMPP, not because
the concept is anything new.

Keep in mind that long poll, BOSH, and RTMPT are all techniques
in use today that attempt to do the same thing.  The reasons that
they don't work very well have nothing to do with the HTTP processors
that are sending content.  SSH, in contrast, works quite well.

In any case, I did not send that message to have a discussion about
what hybi should do.  That topic seems to be closed.  It's as if the
WG were charted to get from the top of a building to the bottom of
a building, and someone argued that the most efficient way to do so
is to step out the window.  *shrug*  Once that decision was made,
arguing about the number of rotations or arm waves seems rather
pointless, at least to me.  YMMV.

I just want the spec to be up front about the impact this will
have on organizational policies.  A sort of "Look out below!"
Because that's the kind of warning that IESG notes are good for.

....Roy=

From w@1wt.eu  Tue Mar 29 11:37:45 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BF23A691B for ; Tue, 29 Mar 2011 11:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.412
X-Spam-Level: 
X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_45=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp1EC9iYeuBU for ; Tue, 29 Mar 2011 11:37:45 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id A3B343A6A82 for ; Tue, 29 Mar 2011 11:37:44 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p2TId2sA015374; Tue, 29 Mar 2011 20:39:02 +0200
Date: Tue, 29 Mar 2011 20:39:02 +0200
From: Willy Tarreau 
To: David Endicott 
Message-ID: <20110329183902.GA15071@1wt.eu>
References:  
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Cc: "Roy T. Fielding" , Server-Initiated HTTP , iesg@iesg.org
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 18:37:46 -0000

On Tue, Mar 29, 2011 at 12:24:00PM -0400, David Endicott wrote:
> Since one of the primary intended uses of Websockets is in the context of
> browser clients & webservers, it would seem to me that allowing the
> client-agent to open the conversation via the webserver (via the HTTP
> Upgrade) makes perfect sense.  I've been working on integrating Websockets
> on the server side both as an independent process and as part of a WSGI
> framework and having it involved with the http server environment is, so
> far, making good sense - the static content and the dynamic content are
> generally related.

The server side is indeed a very important aspect in massive hosting
environments.

Right now, web hosting which offers HTTP+HTTPS basically merges the streams
at the boundary and forwards HTTP only through possibly several layers of
proxies and load balancers to the final server. It makes a lot of sense to
be able to reuse that infrastructure and those existing configurations to
automatically make WebSocket possible on those sites. Having to run the
connections via a specific path (and configuration) for the same site is
going to double the work needed to enable the service, which will sensibly
increase its deployment & maintenance cost, and slow down its adoption.

Also, we're much concerned about the ability to quickly detect failures.
When a site is reachable on port 80, we know this channel is open. That
does not mean that websocket will work over that channel, but at least it
is worth trying it. If we used another port, we have no way to know whether
the other port will pass or not, and the typical "firewall silent drop"
that will happen everywhere ports other than 80 are blocked is the worst
behaviour we can dream of, because no feedback is returned to the user
until a connection timeout strikes.

Regards,
Willy


From w@1wt.eu  Tue Mar 29 11:53:42 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0AA3A6863 for ; Tue, 29 Mar 2011 11:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.973
X-Spam-Level: 
X-Spam-Status: No, score=-2.973 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RK8olyB0xmg for ; Tue, 29 Mar 2011 11:53:42 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 3B7363A682B for ; Tue, 29 Mar 2011 11:53:42 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p2TIsvEo015396; Tue, 29 Mar 2011 20:54:57 +0200
Date: Tue, 29 Mar 2011 20:54:57 +0200
From: Willy Tarreau 
To: "Roy T. Fielding" 
Message-ID: <20110329185457.GB15071@1wt.eu>
References:   <0FA21125-669C-407F-9A3F-A7BE0F1362AA@gbiv.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0FA21125-669C-407F-9A3F-A7BE0F1362AA@gbiv.com>
User-Agent: Mutt/1.4.2.3i
Cc: Server-Initiated HTTP , iesg@iesg.org
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 18:53:42 -0000

On Tue, Mar 29, 2011 at 08:33:36PM +0200, Roy T. Fielding wrote:
> My concern is about the nature of the protocol after the Upgrade
> handshake is complete.  WebSockets will not have the same performance
> characteristics as the Web.  The connection will stay open a long time,
> the messages will be small and occasional in nature, and the TCP
> association will persist.  All of those are *good* things if the
> surrounding network infrastructure (all the machines that those
> bits pass through on their way to the origin server and back) is
> prepared for that type of interaction.  If not, then they will be
> seen as the equivalent of a denial of service attack.

Generally the issues with long connections are not on the infrastructure
in the middle but rather with a threaded origin server that can't accept
many connections and which reserves a lot of resources for an HTTP session,
waiting for an application component to dare respond.

HTTP timeouts will obviously always be an issue, but at least now we'll be
more on "tunnel" timeouts (comparable to what can happen through proxies
after a CONNECT request) than response timeouts. Also, WS makes a difference
between expected and unexpected closes, in order to be able to reconnect if
the close is unexpected. Maybe we should add more restrictions on the
reconnect algorithm to use ? That said, whatever the port, if connection
floods happen, they will always look like DoS attacks.

> I am not concerned about the HTTP-aware message processors.
> They have the ability to decline the Upgrade.  Other forms
> of load-balancing routers do not.

I disagree here. Routers are the least impacted equipments on the chain.
You can have firewalls, but they'll suffer the same from a large number
of connections on any port. Load balancers are designed to deal with very
large amounts of concurrent connections and nowadays are L7-aware, so they
will even be able to affect different service qualities depending on the
presence of the Upgrade header, or serve them on different server farms.

> Nevertheless, your belief does not match deployed network
> management products.  We put different architectures on different
> standard ports in order to make network admins lives easier.

That's true, but security admins tend to prefer it the other way
around, the less open ports, the less attack vectors. Also, due to
the generalization of keep-alive, HTTP connections tend to last long
too nowadays, so I really don't see that much of a difference between
both types of traffic.

When you look at an HTTP connection, you'll find many short exchanges
with short and medium pauses in between (tens of ms and seconds). WS
will basically look like that too.

> Keep in mind that long poll, BOSH, and RTMPT are all techniques
> in use today that attempt to do the same thing.  The reasons that
> they don't work very well have nothing to do with the HTTP processors
> that are sending content.  SSH, in contrast, works quite well.

Interestingly, from where I work, my SSH passes over a long HTTPS chain
all the way to home, because that's the only service I have access to,
and my connections happily last the whole day :-)

Regards,
Willy


From ibc@aliax.net  Tue Mar 29 12:10:37 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5046B3A6A25 for ; Tue, 29 Mar 2011 12:10:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.635
X-Spam-Level: 
X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=0.042,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgYEqom7VQqI for ; Tue, 29 Mar 2011 12:10:36 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 598203A698A for ; Tue, 29 Mar 2011 12:10:36 -0700 (PDT)
Received: by qyk29 with SMTP id 29so2116635qyk.10 for ; Tue, 29 Mar 2011 12:12:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.75.196 with SMTP id z4mr151949qcj.277.1301425934301; Tue, 29 Mar 2011 12:12:14 -0700 (PDT)
Received: by 10.229.35.72 with HTTP; Tue, 29 Mar 2011 12:12:13 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 29 Mar 2011 21:12:13 +0200
Message-ID: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
To: Hybi 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [hybi] Clarify wheter HTTP responses other than 101 are valid
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 19:10:37 -0000

2011/3/27 I=C3=B1aki Baz Castillo :
> So, could a websocket server reply 401 in order the WS client to
> resend the handshake request containing credentials?
> Could a websocket server reply a 3XX response to make a redirection?
> Could a websocket server reply 403 to indicate the client that it's
> not allowed for this service?
> Could the websocket server reply 404 in case the request URI doesn't
> exist in the server?

One more question in this topic:

Usually most protocols have a response code for indicating server
failure (for example a HTTP server can reply 500/503 in case it has
detected an error atr server side, or perhaps it's congested thsi
time). What about WebSocket? do we assume that the WS server should
never indicate the client an error in server side?
Of course, the most appropriate response would be a 500/503 during the
handshake, this is, making the handshake a fully HTTP requests (not
just the request, but also the responses).

The draft should, IMHO, tell about it. If not, WS clients wouldn't be
ready for handling server errors (each WS client developer would
decide what to do in that case as the draft says absolutely nothing
about it).

Regards.


--=20
I=C3=B1aki Baz Castillo


From bruce@callenish.com  Tue Mar 29 12:47:08 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA25B3A6A9E for ; Tue, 29 Mar 2011 12:47:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level: 
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogneJsvhDbAx for ; Tue, 29 Mar 2011 12:47:07 -0700 (PDT)
Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id B7B4F3A6A64 for ; Tue, 29 Mar 2011 12:47:07 -0700 (PDT)
Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q4euD-0005fu-54; Tue, 29 Mar 2011 12:48:45 -0700
Message-ID: <4D92379C.4070209@callenish.com>
Date: Tue, 29 Mar 2011 12:48:44 -0700
From: Bruce Atherton 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: "Roy T. Fielding" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - callenish.com
Cc: Server-Initiated HTTP , iesg@iesg.org
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 19:47:08 -0000

On 29/03/2011 5:23 AM, Roy T. Fielding wrote:
> I only ask that an IESG note be added to the final specification
> to the effect that this protocol knowingly misuses the Internet
> for the sake of bypassing organizational security.  Be honest and
> let the admins make their own decisions.

I understand what you are saying, but can you at least accept that some 
people might not believe that this is a misuse of the Internet? That an 
argument can be made that this is a perfectly legitimate use of Upgrade?

When you take the inflammatory rhetoric out of it, it sounds like you 
are asking for a note warning that Websockets is a different protocol 
than HTTP and could well have traffic that looks different. Is this 
really a surprise to anyone? Is it necessary to issue a warning about that?


From dave@cridland.net  Tue Mar 29 13:21:40 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD6028C0E9 for ; Tue, 29 Mar 2011 13:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.232
X-Spam-Level: 
X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=1.367,  BAYES_00=-2.599, GB_I_INVITATION=-2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY+aDrmZUc5n for ; Tue, 29 Mar 2011 13:21:38 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 4507828C0E4 for ; Tue, 29 Mar 2011 13:21:37 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id E65F81168087; Tue, 29 Mar 2011 21:23:09 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-35NKLqJ0zm; Tue, 29 Mar 2011 21:23:07 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 645881168067; Tue, 29 Mar 2011 21:23:07 +0100 (BST)
References: 
In-Reply-To: 
MIME-Version: 1.0
Message-Id: <4126.1301430187.376151@puncture>
Date: Tue, 29 Mar 2011 21:23:07 +0100
From: Dave Cridland 
To: "Roy T\. Fielding" , "iesg@iesg.org" , Server-Initiated HTTP 
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 20:21:40 -0000

Roy,

I didn't want to reply to this too hastily, because it is in no small  
part an invitation to throw away almost everything we have and start  
over, but nonetheless I suspect that it's worthwhile carefully  
evaluating what you say.

On Tue Mar 29 13:23:33 2011, Roy T. Fielding wrote:
> I am finding it difficult to participate in hybi in any meaningful
> way due to the very poor assumption that websockets traffic should
> use the same ports as Web traffic.  Apparently, this "decision" was
> made on the basis of hums at an in-person WG meeting and the chairs
> believe it to be consensus (and thus quash any discussion that has
> apparent consensus due to the extent to which people keep bringing
> up old issues).  It might even make some sense, given the name of
> this working group.
> 
> 
By using grammatically incorrect quotes around the word "decision",  
you appear to be strongly implying that the consensus arrived at  
there is invalid. I'd like to note SM's detailing of this point - it  
was, in fact, one of the least contentious items this working group  
has ever agreed upon. So please accept that the decision was made for  
good reason, with the facts we had at the time carefully weighed. The  
question worth posing is whether sufficient new facts have come to  
light that we should consider revisiting this decision whilst we  
still can.


> Unfortunately, it is a fatal error.  The rest of the protocol
> discussion is predicated on it, and enormously complex, for the
> sole reason of that initial error in design.  More the pity.
> It assumes that the network infrastructure that currently
> monitors and balances traffic over 80/443 is going to instantly
> adapt to TCP-over-HTTP, as opposed to treating it like a denial
> of service attack.
> 
> 
> 
The implication here is that it is a decision that needs revisiting.

I appreciate that the simplest way to address this comment is to  
declare it too late, but I'd like to highlight the first reason you  
give - that "the rest of the protocol discussion is predicated on  
it". This, I think, is worthwhile to consider - the masking, the HTTP  
upgrade handshake, and so on are all solely there to combat issues  
relating to the choice to run over a network expecting HTTP. In fact,  
not only that, but they're there to combat the problem that the  
intermediaries and other actors within this network don't even fully  
understand HTTP.


> Browsers are fully capable of opening up new ports in firewalls
> simply by concerted use of open standards.  Many other applications
> do so without this painful corruption of existing protocols. Yes,
> it takes time (but not as much time as one would think).  Yes,
> there will be some companies that forcibly block some ports,
> just like there are some companies that forcibly block HTTP
> sites like facebook.com.  That is their right.  If the protocol
> is safe to use, it will be deployable over time.  If not, then
> it shouldn't make the Web situation worse by increasing the
> amount of packet filtering at firewalls.
> 
> 
This is true; however one assumes that if companies are able to block  
Facebook, they can also choose to block Websockets. In fact I suspect  
that companies blocking specific sites might well end up blocking  
WebSockets as well by default, as they're likely to treat it as  
erroneous traffic as you hint above.


> So, I don't think the hybi work is worth continuing.  The rest of
> the protocol decisions simply don't matter -- any of the already
> deployed proprietary hacks are better by default because they
> are no worse than hybi and don't have the imprimatur of the IETF.
> I'd rather develop a protocol that works with network administration
> rather than against it.
> 
> 
The question is not simply whether you consider the hybi work  
worthwhile to continue, however.


> I only ask that an IESG note be added to the final specification
> to the effect that this protocol knowingly misuses the Internet
> for the sake of bypassing organizational security.  Be honest and
> let the admins make their own decisions.

At this point in time, I don't think this is suitable; we should  
either consider changing the protocol or decide that what we have is  
indeed correct, even in the face of the difficulties of passing  
through the HTTP layer.

So either we:

1) Continue to use port 80 and HTTP Upgrade, and by inference we need  
masking, fast-fail detection in the Upgrade, and so on, or:

2) Switch to a different port and by inference drop any need for  
masking. (We'd still need a fast-fail handshake, to avoid  
cross-protocol attacks, but we could this time consider other designs  
entirely).

I suspect, without looking, that we have spent approximately the past  
9 months solely on issues relating to the use of HTTP. On the one  
hand, we're approaching what seems like a solution, and moreover,  
this is a sunk cost. On the other, it's entirely possible that we  
might find another issue with running over the HTTP network, and  
switching to a different port (or rather, switching to having no  
expectation that we're running over HTTP) would entirely liberate us.  
But to change means throwing away 9 months of work, which means it  
simply cannot be a quick decision.

So rather than suggest any kind of decision be made at this point,  
I'd like to instead ask this:

If I (and anyone else interested) were to go away - by which I mean  
form a small design team off this list - and come back in a week or  
two with a complete proposal which is based around the premise of  
*not* using HTTP, does the group feel it would be able to consider it?

I'm suggesting bringing a complete I-D, essentially close to  
RFC-ready in the eyes of those involved, and not drawing on the  
group's energy at this time to write it.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From fielding@gbiv.com  Tue Mar 29 13:34:28 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97EF328B797 for ; Tue, 29 Mar 2011 13:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoaKjlU2DXEQ for ; Tue, 29 Mar 2011 13:34:22 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by core3.amsl.com (Postfix) with ESMTP id C2C653A6A88 for ; Tue, 29 Mar 2011 13:34:22 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 2F50E6B007C; Tue, 29 Mar 2011 13:36:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=G/USsPelPOQJegN2 eco2Df0qnBTMuTMgeSuVbm0Qnd1ZWxgO0SuuqlnFXN3IT1MJ7EyK7Zl8L2/IwlFU HFaQ0deqDtSRayrbOejQUrsYEwD5odGY34OQYUL3bnKQW+zA6iXbQ/lSDCpDc+Pa SwZjlBHqMMsLkmbKXTNaJmDomxM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=WsXw2vwRpfzAlIAr7WWSjzCTgJM=; b=zfDcp5mKglF1O3sRQcyU5MVr/cWq bcAqbQVBgITwbtzN/OdjARqKkWwUyjte7GjCTBVgMsvUY9gLOxI0n6R/OgDWClAf lDgWGC3OsuE7hE/Es2GCxnC2ddTmc8h8qWaqCqesHXip0wwEGI6ccKq0nK+nrcWo sbTKXL5ogyha1qA=
Received: from [192.168.222.66] (unknown [109.107.209.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 094AA6B007B;  Tue, 29 Mar 2011 13:35:59 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Roy T. Fielding" 
In-Reply-To: <4D92379C.4070209@callenish.com>
Date: Tue, 29 Mar 2011 22:35:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B7321A9-87EF-4947-A296-76EE8C7F1B23@gbiv.com>
References:  <4D92379C.4070209@callenish.com>
To: Bruce Atherton 
X-Mailer: Apple Mail (2.1084)
Cc: Server-Initiated HTTP , iesg@iesg.org
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 20:34:28 -0000

On Mar 29, 2011, at 9:48 PM, Bruce Atherton wrote:

> On 29/03/2011 5:23 AM, Roy T. Fielding wrote:
>> I only ask that an IESG note be added to the final specification
>> to the effect that this protocol knowingly misuses the Internet
>> for the sake of bypassing organizational security.  Be honest and
>> let the admins make their own decisions.
>=20
> I understand what you are saying, but can you at least accept that =
some people might not believe that this is a misuse of the Internet? =
That an argument can be made that this is a perfectly legitimate use of =
Upgrade?

Yes.  The world is full of arguments.  You can put that in an IESG
note as well.  You don't have to agree with me.=20

> When you take the inflammatory rhetoric out of it, it sounds like you =
are asking for a note warning that Websockets is a different protocol =
than HTTP and could well have traffic that looks different. Is this =
really a surprise to anyone? Is it necessary to issue a warning about =
that?

It is a different protocol, with different operational characteristics,
on a reserved port.  That matters to some people.  It may mean that they
need to change their network configuration accordingly, beyond what one
would expect from an apps-area proposed standard.  It may also mean that
they need to update their general-purpose webserver to one that blocks
upgrade by default.  This is the kind of thing that the IETF warns about
when they publish a new spec that does something wonky.

If I knew exactly what damage this will do, I would be more specific.
I tried to stay interested long enough to figure that out, but I found
today's WG meeting to be intolerable.

....Roy


From bruce@callenish.com  Tue Mar 29 13:48:24 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3927D3A6981 for ; Tue, 29 Mar 2011 13:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level: 
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhtwcWkEMSLv for ; Tue, 29 Mar 2011 13:48:23 -0700 (PDT)
Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 750253A68FF for ; Tue, 29 Mar 2011 13:48:23 -0700 (PDT)
Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q4frU-0000iu-Px; Tue, 29 Mar 2011 13:50:00 -0700
Message-ID: <4D9245F7.5090205@callenish.com>
Date: Tue, 29 Mar 2011 13:49:59 -0700
From: Bruce Atherton 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: "Roy T. Fielding" 
References:  <4D92379C.4070209@callenish.com> <2B7321A9-87EF-4947-A296-76EE8C7F1B23@gbiv.com>
In-Reply-To: <2B7321A9-87EF-4947-A296-76EE8C7F1B23@gbiv.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - callenish.com
Cc: Server-Initiated HTTP , iesg@iesg.org
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 20:48:24 -0000

On 29/03/2011 1:35 PM, Roy T. Fielding wrote:
> It is a different protocol, with different operational characteristics,
> on a reserved port.  That matters to some people.

Then surely the note you want belongs on the definition for HTTP 
Upgrade, not on the protocols that legitimately use it.


From dave@cridland.net  Tue Mar 29 14:24:34 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619D53A693D for ; Tue, 29 Mar 2011 14:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.272
X-Spam-Level: 
X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.327,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuvIZ9qkpBci for ; Tue, 29 Mar 2011 14:24:33 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 0A4E83A68FF for ; Tue, 29 Mar 2011 14:24:32 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id F0E371168087; Tue, 29 Mar 2011 22:26:09 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TEdJa6IYc2V; Tue, 29 Mar 2011 22:26:08 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id EE7A51168067; Tue, 29 Mar 2011 22:26:07 +0100 (BST)
References:   <20110329183902.GA15071@1wt.eu>
In-Reply-To: <20110329183902.GA15071@1wt.eu>
MIME-Version: 1.0
Message-Id: <4126.1301433967.942832@puncture>
Date: Tue, 29 Mar 2011 22:26:07 +0100
From: Dave Cridland 
To: Willy Tarreau , "Roy T\. Fielding" , Server-Initiated HTTP , "iesg@iesg.org" , David Endicott 
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 21:24:34 -0000

On Tue Mar 29 19:39:02 2011, Willy Tarreau wrote:
> Also, we're much concerned about the ability to quickly detect  
> failures.
> When a site is reachable on port 80, we know this channel is open.  
> That
> does not mean that websocket will work over that channel, but at  
> least it
> is worth trying it. If we used another port, we have no way to know  
> whether
> the other port will pass or not, and the typical "firewall silent  
> drop"
> that will happen everywhere ports other than 80 are blocked is the  
> worst
> behaviour we can dream of, because no feedback is returned to the  
> user
> until a connection timeout strikes.

Just on this point, it's not entirely clear that we wouldn't have  
connection timeout issues even with an HTTP Upgrade - we have  
generally assumed that intermediaries may choke or otherwise behave  
oddly when faced with websocket traffic, hence the various handshake  
designs.

However, I don't think it'll be much of an issue; the Javascript API  
in use here is highly asynchronous, and so applications can be  
written very easily to handle long startups and potential failure.  
I'd expect content panes within the page being viewed to have default  
content, a warning, splash-screen, etc whilst the WebSocket starts  
up, and it'd have the same effect as the  tags used to back when  
web designers couldn't rely on frames and scripting being available.

Again, this applies in either case.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From dave@cridland.net  Tue Mar 29 14:29:16 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E363A698F for ; Tue, 29 Mar 2011 14:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.281
X-Spam-Level: 
X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.318,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gXWKUuJ+tQ2 for ; Tue, 29 Mar 2011 14:29:13 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 28C733A68FF for ; Tue, 29 Mar 2011 14:29:13 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 5D2CF1168090; Tue, 29 Mar 2011 22:30:50 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6tritMJOLMx; Tue, 29 Mar 2011 22:30:48 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id EB0F11168067; Tue, 29 Mar 2011 22:30:48 +0100 (BST)
References:   <0FA21125-669C-407F-9A3F-A7BE0F1362AA@gbiv.com>
In-Reply-To: <0FA21125-669C-407F-9A3F-A7BE0F1362AA@gbiv.com>
MIME-Version: 1.0
Message-Id: <4126.1301434248.959488@puncture>
Date: Tue, 29 Mar 2011 22:30:48 +0100
From: Dave Cridland 
To: "Roy T\. Fielding" , Server-Initiated HTTP , "iesg@iesg.org" , David Endicott 
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 21:29:16 -0000

On Tue Mar 29 19:33:36 2011, Roy T. Fielding wrote:
> Keep in mind that long poll, BOSH, and RTMPT are all techniques
> in use today that attempt to do the same thing.  The reasons that
> they don't work very well have nothing to do with the HTTP  
> processors
> that are sending content.  SSH, in contrast, works quite well.

Just to piss on all fires equally, the only issue with BOSH I've ever  
been aware of is its bandwidth overhead due to the HTTP framing, and  
that only when compared to bare XMPP in mobile situations -  
otherwise, BOSH has a 100% "penetration" capability and is entirely  
compliant with the HTTP spec (although it does, notoriously, benefit  
from pipelining POST requests). So within the constraint of "runs  
within HTTP", BOSH does indeed "work very well", and to all intents  
and purposes behaves identically to an HTTP processor sending content.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From fielding@gbiv.com  Tue Mar 29 14:53:54 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2C23A6ACB for ; Tue, 29 Mar 2011 14:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ma4geBtB+6L for ; Tue, 29 Mar 2011 14:53:53 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 3883E3A6ACD for ; Tue, 29 Mar 2011 14:53:53 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 9643967C06E; Tue, 29 Mar 2011 14:55:31 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=Ow03rP08oj005EeX bGOEnIHCO/WlkGQlPiNmtNwOZkOik8uRmSnU28XP7odvYPvtXO8NttIZ547IugMF MkWtlYwK8cwGB0im1Y2g/NqDUfY3xjne1g0H34VZcX8CNR+8jSqgfYsdj/orjYu+ XLQjnaea10EHbGFbPx2NwAuOkmY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=fitDhC/MxB8tJjTShQFqUywW5NQ=; b=YuxUcAwYAZ2G52rg8KibsWwnH88H oYZq+55HCBO9fB1ZbuS0S3K5SrSzJJVoUqEMlA5xYqDvx+yi13EATGx5S8ADKgh5 n4GtnaLmpfK0+UdB6p4UHmeHdTg2NuhhLyOhXzpMT/MiQ13e681eB7Gndk93Hune HOpxJCwjZxLyhkU=
Received: from [192.168.222.66] (unknown [109.107.209.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 7802767C06D;  Tue, 29 Mar 2011 14:55:30 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Roy T. Fielding" 
In-Reply-To: <4D9245F7.5090205@callenish.com>
Date: Tue, 29 Mar 2011 23:55:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <4D92379C.4070209@callenish.com> <2B7321A9-87EF-4947-A296-76EE8C7F1B23@gbiv.com> <4D9245F7.5090205@callenish.com>
To: Bruce Atherton 
X-Mailer: Apple Mail (2.1084)
Cc: Server-Initiated HTTP , iesg@iesg.org
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 21:53:54 -0000

On Mar 29, 2011, at 10:49 PM, Bruce Atherton wrote:

> On 29/03/2011 1:35 PM, Roy T. Fielding wrote:
>> It is a different protocol, with different operational =
characteristics,
>> on a reserved port.  That matters to some people.
>=20
> Then surely the note you want belongs on the definition for HTTP =
Upgrade, not on the protocols that legitimately use it.

No.  If people want to find out about this new protocol published
by the IETF, they won't be looking for warnings deep within the
HTTP spec.

HTTP Upgrade's definition is not relevant to this discussion. Why
you keep bringing it up is beyond me, and I'm the guy that invented it.
Upgrade was created specifically to upgrade the protocol to future
incompatible versions of HTTP (HTTPng, waka, or other proposed
replacements for HTTP/1.x that share the same operational behavior
as HTTP but with an incompatible syntax that needs a bootstrap in
order to be deployed).  I have not tested Upgrade with different
architectures, nor do I particularly care whether anyone thinks that
is a legitimate use case.  It simply doesn't matter.  What matters
is what happens after the Upgrade and how that impacts deployed
network architecture.

I'd suggest exactly the same warning if hybi was being performed
without an Upgrade, on a new connection of port 80.

Again, this is only a request for an IESG note.  This is not
reopening the decision in hybi, this is not in scope for the working
group draft, this is not subject to the working group's interesting
method of obtaining consensus by polling people at meetings and then
closing all further discussion on the issue.  What this is, though,
is a request from one of the authors of HTTP to the IESG, because
they can think about it themselves once the issue is brought to
their attention (and I can wash my hands of it).  Normally I would
wait until last call, but the WG chairs have insisted that this
won't be changed and the ADs seem to agree -- so why wait?

....Roy


From gregw@intalio.com  Tue Mar 29 16:06:28 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B45E53A6AD7 for ; Tue, 29 Mar 2011 16:06:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Level: 
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.327,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSUDOdZPhEIv for ; Tue, 29 Mar 2011 16:06:27 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B1F533A6AD6 for ; Tue, 29 Mar 2011 16:06:27 -0700 (PDT)
Received: by vws12 with SMTP id 12so680423vws.31 for ; Tue, 29 Mar 2011 16:08:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.18.6 with SMTP id s6mr603772vdd.144.1301440085790; Tue, 29 Mar 2011 16:08:05 -0700 (PDT)
Received: by 10.52.155.71 with HTTP; Tue, 29 Mar 2011 16:08:05 -0700 (PDT)
In-Reply-To: 
References:  <4D92379C.4070209@callenish.com> <2B7321A9-87EF-4947-A296-76EE8C7F1B23@gbiv.com> <4D9245F7.5090205@callenish.com> 
Date: Wed, 30 Mar 2011 10:08:05 +1100
Message-ID: 
From: Greg Wilkins 
To: "Roy T. Fielding" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Server-Initiated HTTP , iesg@iesg.org
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 23:06:28 -0000

On 30 March 2011 08:55, Roy T. Fielding  wrote:
> HTTP Upgrade's definition is not relevant to this discussion. Why
> you keep bringing it up is beyond me, and I'm the guy that invented it.
> Upgrade was created specifically to upgrade the protocol to future
> incompatible versions of HTTP (HTTPng, waka, or other proposed
> replacements for HTTP/1.x that share the same operational behavior
> as HTTP but with an incompatible syntax that needs a bootstrap in
> order to be deployed). =A0I have not tested Upgrade with different
> architectures, nor do I particularly care whether anyone thinks that
> is a legitimate use case. =A0It simply doesn't matter. =A0What matters
> is what happens after the Upgrade and how that impacts deployed
> network architecture.

Roy,

I hate to quibble with the author, but RFC2616 says:

 "The Upgrade header field is intended to provide a simple mechanism
for transition from HTTP/1.1 to some other, incompatible protocol."

and the examples listed include IRC and RTA/x11.      So it does not
appear that the specification reflects the limited scope that you
suggest for upgrade.   I also question the wisdom of having an upgrade
mechanism that only supports protocols that can be imagined at the
time the mechanism was specified.

Also, consider an upgrade to TLS, which RFC2817 implies is an intended
use for the mechanism. In many ways an upgrade to TLS is similar to
upgrade to websockets:
  + after the upgrade the framing is no longer HTTP framing, but TLS,
so the intermediaries may have to adopt different data forwarding
strategies
  +  content filters/loggers can no longer inspect HTTP
request/responses and have to consider applying a blanket block or
allowing all content unfiltered.
  + once upgraded to TLS, the protocol on the wire has closing
handshakes that would be best respected rather than having
intermediaries timeout the connection (silently or otherwise).
Such TLS connections would benefit from declared timeouts/keep-alive
values as well as websocket.
 + the ability to renegotiate on TLS (Eg ask for client certs etc)
also means that the data flow is not a pure client server
conversation, so intermediaries will have to be bidirection.

So I think people bring up upgrades definition because if
intermediaries we able to be written to well support upgrade to TLS
(or other protocols), then they should be able to support something
like websocket.

In fact, for many intermediaries, upgrade to websocket should be
better than upgrade to TLS, because hopefully they will be able to see
well defined framing that will allow them to have sane forwarding and
content inspection policies (of course things like stream-deflate and
other extensions that mess with the framing make this less so).

So rather than an abuse of the upgrade mechanism - I see that
websockets is requiring that intermediaries have good implementations
of it.   I think websockets also highlights existing flaws with lack
of knowledge of timeouts on intermediaries.


regards

From bruce@callenish.com  Tue Mar 29 16:16:32 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857EC3A6AA2 for ; Tue, 29 Mar 2011 16:16:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Level: 
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyHGjZ9d5Tto for ; Tue, 29 Mar 2011 16:16:31 -0700 (PDT)
Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id B94C63A6992 for ; Tue, 29 Mar 2011 16:16:31 -0700 (PDT)
Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q4iAq-0002p6-RU; Tue, 29 Mar 2011 16:18:08 -0700
Message-ID: <4D9268B0.4060500@callenish.com>
Date: Tue, 29 Mar 2011 16:18:08 -0700
From: Bruce Atherton 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: "Roy T. Fielding" 
References:  <4D92379C.4070209@callenish.com> <2B7321A9-87EF-4947-A296-76EE8C7F1B23@gbiv.com> <4D9245F7.5090205@callenish.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - callenish.com
Cc: Server-Initiated HTTP , iesg@iesg.org
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 23:16:32 -0000

On 29/03/2011 2:55 PM, Roy T. Fielding wrote:
> On Mar 29, 2011, at 10:49 PM, Bruce Atherton wrote:
>
>> On 29/03/2011 1:35 PM, Roy T. Fielding wrote:
>>> It is a different protocol, with different operational characteristics,
>>> on a reserved port.  That matters to some people.
>> Then surely the note you want belongs on the definition for HTTP Upgrade, not on the protocols that legitimately use it.
> No.  If people want to find out about this new protocol published
> by the IETF, they won't be looking for warnings deep within the
> HTTP spec.

Anyone looking at the Websockets spec is going to realize very quickly 
that it is a "different protocol" and that it uses the same default 
ports as HTTP. The people I would worry about (if I thought this issue 
was worth worrying about) are the ones who are unaware of and have no 
interest in Websockets, but that do have an interest in HTTP and are 
likely to keep up on the HTTP spec.

> HTTP Upgrade's definition is not relevant to this discussion. Why
> you keep bringing it up is beyond me, and I'm the guy that invented it.

I bring it up is because it is the standard-blessed method of switching 
an HTTP connection to a different protocol. This use is not the one you 
envisioned for it, but I haven't seen anyone claim this use is in 
violation of any spec. Any number of different protocols, both standard 
and proprietary, could (and perhaps eventually will) do the same thing.

If switching the protocol from HTTP is such a concern, then the proper 
place to address it is where the definition for switching is defined.

> I'd suggest exactly the same warning if hybi was being performed
> without an Upgrade, on a new connection of port 80.

Fair enough. Then the warning you want should go on the identification 
of port 80 as the default in the HTTP spec, mentioning that it is 
possible for non-HTTP servers, or HTTP servers that also spoke different 
protocols, to be listening on it. I think most people would categorize 
the warning as belonging to the category of "bleedin' obvious", but that 
is just my opinion.


From Joe.Hildebrand@webex.com  Tue Mar 29 16:50:24 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C5DE3A6A8F for ; Tue, 29 Mar 2011 16:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.438
X-Spam-Level: 
X-Spam-Status: No, score=-104.438 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98Jg5zGwtEIu for ; Tue, 29 Mar 2011 16:50:23 -0700 (PDT)
Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by core3.amsl.com (Postfix) with SMTP id 248523A6960 for ; Tue, 29 Mar 2011 16:50:22 -0700 (PDT)
Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 29 Mar 2011 16:52:01 -0700
Received: from 66.114.169.8 ([66.114.169.8]) by SRV-EXSC03.webex.local ([192.168.252.200]) via Exchange Front-End Server mailus.webex.com ([66.114.175.11]) with Microsoft Exchange Server HTTP-DAV ; Tue, 29 Mar 2011 23:52:00 +0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Wed, 30 Mar 2011 01:51:59 +0200
From: Joe Hildebrand 
To: "Roy T. Fielding" , Bruce Atherton 
Message-ID: 
Thread-Topic: [hybi] reuse of port 80/443 in hybi
Thread-Index: AcvubErbxSckPcjlAUuHBye8Z7CqtA==
In-Reply-To: 
IM-ID: xmpp:jhildebr@cisco.com
Presence-ID: xmpp:jhildebr@cisco.com
Jabber-ID: jhildebr@cisco.com
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 29 Mar 2011 23:52:01.0276 (UTC) FILETIME=[4C3743C0:01CBEE6C]
Cc: Server-Initiated HTTP , iesg@iesg.org
Subject: Re: [hybi] reuse of port 80/443 in hybi
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2011 23:50:24 -0000

On 3/29/11 11:55 PM, "Roy T. Fielding"  wrote:

> this is not subject to the working group's interesting
> method of obtaining consensus by polling people at meetings and then
> closing all further discussion on the issue.

To be clear, the intent was to see if any progress could be made on an issue
that has had us blocked for quite a while, fashion a proposal that would be
sent to the list, and have discussion on the proposal on the list before any
consensus was declared.  We were running out of time at the end and didn't
make that clear, for which I absolutely apologize.

As well and as others have mentioned, we've had a history of folks with less
deeply thought-out opinions than the ones you've expressed stopping by the
working group to derail the tenuous progress we've been able to eke out by
revisiting everything we all dislike but are just barely willing to all
tolerate.  As such, there are more antibodies than usual to newcomers, for
which we probably ought to post an apology to the list once a week.
Unfortunately, there's so much traffic I doubt anyone would see it.

What we have said repeatedly is that the final document will have to reflect
the consensus of the working group, including anything we've decided to put
on hold so that we could make progress in other areas.  If the people with
issues are still around by the time we get to WGLC, the group would have to
deal with those issues.

This is all Sal and Gabriel's issue now; I just wanted to clarify what was
intended at the time.

-- 
Joe Hildebrand
(as individual!)


From alexey.melnikov@isode.com  Wed Mar 30 00:54:16 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ECEF3A6A98 for ; Wed, 30 Mar 2011 00:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.503
X-Spam-Level: 
X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTFMabihL3x6 for ; Wed, 30 Mar 2011 00:54:15 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 837DA28C0EF for ; Wed, 30 Mar 2011 00:54:15 -0700 (PDT)
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id ; Wed, 30 Mar 2011 08:55:53 +0100
Message-ID: <4D92E1F7.2080509@isode.com>
Date: Wed, 30 Mar 2011 09:55:35 +0200
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: hybi@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [hybi] Change of WG chairs/ADs
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2011 07:54:16 -0000

Dear WG participants,
My IESG term ends tonight, so after some discussions with my co-ADs, we 
decided that Peter Saint-Andre is going to be your responsible AD 
starting from Thursday.
As Peter is working closely with Joe, Joe agreed to step down as a WG 
co-chair. Gabriel Montenegro is going to be a new co-chair together with 
Salvatore.

I would personally like to thank Joe for the effort of keeping this WG 
moving.

Best Regards,
Alexey

-- 
IETF Application Area Director, 
Internet Messaging Team Lead, 
JID: same as my email address



From Gabriel.Montenegro@microsoft.com  Wed Mar 30 04:12:50 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC12C28C152 for ; Wed, 30 Mar 2011 04:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.516
X-Spam-Level: 
X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STN9ZspAOkFH for ; Wed, 30 Mar 2011 04:12:50 -0700 (PDT)
Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id E532328C137 for ; Wed, 30 Mar 2011 04:12:49 -0700 (PDT)
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 30 Mar 2011 04:14:28 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 30 Mar 2011 04:14:28 -0700
Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.217]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Wed, 30 Mar 2011 04:14:28 -0700
From: Gabriel Montenegro 
To: Alexey Melnikov , "hybi@ietf.org" , "Joe Hildebrand (joe.hildebrand@webex.com)" 
Thread-Topic: [hybi] Change of WG chairs/ADs
Thread-Index: AQHL7q/qq/wVZOPuM0W1tJCMp1uk1JRFuSSQ
Date: Wed, 30 Mar 2011 11:14:28 +0000
Message-ID: 
References: <4D92E1F7.2080509@isode.com>
In-Reply-To: <4D92E1F7.2080509@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.123.12]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [hybi] Change of WG chairs/ADs
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2011 11:12:51 -0000

I want to second the expression of gratitude to Joe for his co-chairing up =
to now, and to Alexey for his role as AD. I am hopeful that we'll continue =
to benefit from both of their contributions even after the role changes.

> -----Original Message-----
> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
> Alexey Melnikov
> Sent: Wednesday, March 30, 2011 09:56
> To: hybi@ietf.org
> Subject: [hybi] Change of WG chairs/ADs
>=20
> Dear WG participants,
> My IESG term ends tonight, so after some discussions with my co-ADs, we
> decided that Peter Saint-Andre is going to be your responsible AD startin=
g from
> Thursday.
> As Peter is working closely with Joe, Joe agreed to step down as a WG co-=
chair.
> Gabriel Montenegro is going to be a new co-chair together with Salvatore.
>=20
> I would personally like to thank Joe for the effort of keeping this WG mo=
ving.
>=20
> Best Regards,
> Alexey
>=20
> --
> IETF Application Area Director, 
> Internet Messaging Team Lead, 
> JID: same as my email address
>=20
>=20
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi


From ietf@meetecho.com  Wed Mar 30 10:46:44 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E28D3A6A44 for ; Wed, 30 Mar 2011 10:46:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.22
X-Spam-Level: 
X-Spam-Status: No, score=0.22 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVjKiUIn+oCW for ; Wed, 30 Mar 2011 10:46:43 -0700 (PDT)
Received: from smtpw1.aruba.it (smtpa1.aruba.it [62.149.128.210]) by core3.amsl.com (Postfix) with SMTP id A53FC3A6BA9 for ; Wed, 30 Mar 2011 10:46:42 -0700 (PDT)
Received: (qmail 1121 invoked by uid 89); 30 Mar 2011 17:48:16 -0000
Received: from unknown (HELO aruba.it) (62.149.158.91) by smtpw1.ad.aruba.it with SMTP; 30 Mar 2011 17:48:16 -0000
Date: Wed, 30 Mar 2011 19:48:17 +0200
Message-Id: 
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: multipart/alternative; boundary="_=__=_XaM3_.1301507297.2A.539812.42.2413.52.42.007.963595257"
From: "ietf@meetecho.com" 
To: hybi@ietf.org
X-XaM3-API-Version: V3(R2)
X-SenderIP: 130.129.20.143
X-Spam-Rating: smtpw1.ad.aruba.it 1.6.2 0/1000/N
Subject: [hybi] HYBI recording available
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2011 17:46:44 -0000

--_=__=_XaM3_.1301507297.2A.539812.42.2413.52.42.007.963595257
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Dear all,the full recording (synchronized video, audio, slides and jabber=
 room) of yesterday's HYBI session is available at the following URL:http=
://ietf.conf.meetecho.comWe apologize for the bad audio quality on the fi=
rst 20 minutes of the recording.We were not able to attach to the main au=
dio stream before that time (the first minutes are taken live from the ro=
om speakers).In case of problems with the playout, just drop an e-mail to=
 ietf-support@meetecho.com.Cheers,Meetecho Team

--_=__=_XaM3_.1301507297.2A.539812.42.2413.52.42.007.963595257
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=0A
=0A
Dear all,

the full recording (synchroni=
zed video, audio, slides and jabber room) 
of yesterday's HYBI session=
 is available at the following URL:

http://ietf.conf.meetecho.co=
m

We apologize for the bad audio quality on the first 20 minut=
es of the recording.
We were not able to attach to the main audio stre=
am before that time (the first minutes are taken live from the room speak=
ers).

In case of problems with the playout, just drop an e-mail to=
 
ietf-support@meetecho.com.

Cheers,
Meetecho Tea=
m
=0A
=0A

--_=__=_XaM3_.1301507297.2A.539812.42.2413.52.42.007.963595257--


From phil127@gmail.com  Wed Mar 30 12:15:41 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B73223A6BB3 for ; Wed, 30 Mar 2011 12:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNm8PGaIUTQj for ; Wed, 30 Mar 2011 12:15:40 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 816F33A6A74 for ; Wed, 30 Mar 2011 12:15:40 -0700 (PDT)
Received: by wyb29 with SMTP id 29so1549021wyb.31 for ; Wed, 30 Mar 2011 12:17:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:x-enigmail-version:content-type:content-transfer-encoding; bh=UhZ91MoLDtBZogETwSFyc5uPn6Lxlxn+M5EXThKij34=; b=BE/K67g70QcOBL17Qx+4qB7yocgbeKYKqliSEtyJFBqx+8nzk/3SnNKWeR7BZXYhk5 TlYDA7Q6c9baV6n8gTnKt0x5HsaEBPaUkGz+WuHSl/yBtPPuUc3iitKXt/AvPfk1QGSe DS2gUfkID9+Be0NmY3PLAnjA+WvRRVSzCJtu8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=MHdaEvJaAOq7CIjnhaMnZcEGdDO4nmNduxAbFMbyRHdi+oECmIQS48JM7Qf53WOrdV +diwbPcCPSXS1PnHYl4Z4Tv9HbBZn2vYWM01bTSpKILWjTmEWwQiRDdzSI2WEc0XLxBa wUHN0PsKRkGNlunXKQ/hyJ5HDZph0xaZGnLP8=
Received: by 10.227.200.129 with SMTP id ew1mr1761607wbb.130.1301512639031; Wed, 30 Mar 2011 12:17:19 -0700 (PDT)
Received: from [212.201.70.87] (pptp-212-201-70-87.pptp.stw-bonn.de [212.201.70.87]) by mx.google.com with ESMTPS id o6sm228359wbo.3.2011.03.30.12.17.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 12:17:16 -0700 (PDT)
Message-ID: <4D93818C.8030702@gmail.com>
Date: Wed, 30 Mar 2011 21:16:28 +0200
From: Philipp Serafin 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: hybi@ietf.org
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [hybi] Regarding "what parts of a frame should be masked"
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2011 19:15:41 -0000

Hello everyone,

in the HYBI session yesterday, there was a discussion about whether the
whole part of a WS frame should be masked or only payload and extension
data. The question was then moved to the mailing list.
I'm a CS student who is following this list out of interest (so please
forgive me if I say something stupid - I'll try not to :) ) and I
started roughly implementing the current draft to play around with the
technology.

I noticed that implementing the masking becomes somewhat easier if the
length field is not masked. Because the masking key changes with each
frame, you obviously need to know the length of the frame before you can
unmask anything past the header. If the header (particularly the length
field) is masked as well, this means you need a separate unmasking
routine for the header. In contrast, if the length is unmasked, you can
simply read the whole frame into a buffer and then unmask it in one go.

Both options are definitely "I can live with it". However, since there
didn't seem to be any strong points for or against either option in the
meeting, I'd like to give implementation complexity as an argument in
favour of "don't mask the header".

Regards,
Philipp Serafin

From andy.warmcat.com@googlemail.com  Wed Mar 30 12:39:47 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336A528C0DE for ; Wed, 30 Mar 2011 12:39:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.588
X-Spam-Level: 
X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM3scNx+ccUf for ; Wed, 30 Mar 2011 12:39:46 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id BE63928C18B for ; Wed, 30 Mar 2011 12:39:45 -0700 (PDT)
Received: by wwa36 with SMTP id 36so1366373wwa.13 for ; Wed, 30 Mar 2011 12:41:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rwfPxyKX6FjoS7Kf1TIK2QF5lCSD2QuR0YMmGCw6+mk=; b=PWMPIPcBJemfok6GUFguxl0PxWByCqJ64rsDHGYPeE1DnEYpJ7L8MeMaKI5r40HGhv fdG60MZ24gI+hX293N7I5vcIMx70XhmWG6SrmiObkuwKF7bTSRpGyNPQg3IjVSs/tR// sqGx49BZ3+QLxy2d1Ii6gXFL4AlPbMijk+Jt0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=N5DsAfJuIQAip6PNU46um1XyJSCjq8U/ZKqXkEQw+FxmMkxUTFZ2+00irP6uMJGsQD ALWiUxbCeaXi7uGz3u78OEVFDtTIepjhb6d8fqPgWW+EH9KCJQaFjDmCDYWO7xI3Id2z Rq3t7BS9VNipKVPr87PWW2Ly7qCsRY5/bb6zA=
Received: by 10.216.168.82 with SMTP id j60mr1126101wel.47.1301514083713; Wed, 30 Mar 2011 12:41:23 -0700 (PDT)
Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id o6sm236339wbo.37.2011.03.30.12.41.22 (version=SSLv3 cipher=OTHER); Wed, 30 Mar 2011 12:41:23 -0700 (PDT)
Sender: Andy Green 
Message-ID: <4D938761.9000502@warmcat.com>
Date: Wed, 30 Mar 2011 20:41:21 +0100
From: Andy Green 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110310 Fedora/3.1.9-2.fc16 Thunderbird/3.1.9
MIME-Version: 1.0
To: Philipp Serafin 
References: <4D93818C.8030702@gmail.com>
In-Reply-To: <4D93818C.8030702@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Regarding "what parts of a frame should be masked"
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2011 19:39:47 -0000

On 03/30/2011 08:16 PM, Somebody in the thread at some point said:
> Hello everyone,
>
> in the HYBI session yesterday, there was a discussion about whether the
> whole part of a WS frame should be masked or only payload and extension
> data. The question was then moved to the mailing list.
> I'm a CS student who is following this list out of interest (so please
> forgive me if I say something stupid - I'll try not to :) ) and I
> started roughly implementing the current draft to play around with the
> technology.
>
> I noticed that implementing the masking becomes somewhat easier if the
> length field is not masked. Because the masking key changes with each
> frame, you obviously need to know the length of the frame before you can
> unmask anything past the header. If the header (particularly the length
> field) is masked as well, this means you need a separate unmasking
> routine for the header. In contrast, if the length is unmasked, you can
> simply read the whole frame into a buffer and then unmask it in one go.
>
> Both options are definitely "I can live with it". However, since there
> didn't seem to be any strong points for or against either option in the
> meeting, I'd like to give implementation complexity as an argument in
> favour of "don't mask the header".

I agree with you.

It's worth reviewing this thread from 8th March

http://www.ietf.org/mail-archive/web/hybi/current/msg06796.html

which clearly sets out that and other views so you can understand the 
environment around the issue as well as the issue itself.

-Andy

From theturtle32@gmail.com  Wed Mar 30 13:46:11 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81A283A6A88 for ; Wed, 30 Mar 2011 13:46:11 -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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqZzBkIoWVI8 for ; Wed, 30 Mar 2011 13:46:10 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 86EAC3A698D for ; Wed, 30 Mar 2011 13:46:10 -0700 (PDT)
Received: by iye19 with SMTP id 19so1882031iye.31 for ; Wed, 30 Mar 2011 13:47:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=qX+uaHCY/6zOXYXsbLVnoS+Eokm+1YXbg5ywsHnDqYw=; b=RlIl0kkIXyzUSlebpr2ZlUnwCI1DaRublaot3FFt6SyN/MgHiUEx44Esv+vo/AHW8Z y6GA2+mO+YkSKCK84JZT4N7EQiry5awzFN2ackYz1+MDBfruvqdzCpFqf52TOVOU4WGi lvQCa1rNgWw8DQX6eNAi4q/WpcscbTE4hcFu0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=MLc5M18RvKqfiXpJoW+j4UR8bZ8+lRt3N0VfXPXTsKe7mM1dz2R+tVFemm4SRzPk6e PZNnoQJ0CgDu3/JkwUIJejmP8ICR2h5/J4GHYuL/w92uLHuqCrz4jkwMANJRu3doFWGg aB8C0poy0fu7r0r1ovh1JutNjh65wQWyjz7io=
Received: by 10.231.187.165 with SMTP id cw37mr1753398ibb.88.1301518069505; Wed, 30 Mar 2011 13:47:49 -0700 (PDT)
Received: from [10.101.109.20] ([166.205.138.223]) by mx.google.com with ESMTPS id 13sm243986ibo.59.2011.03.30.13.47.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 13:47:48 -0700 (PDT)
References: <4D93818C.8030702@gmail.com> <4D938761.9000502@warmcat.com>
In-Reply-To: <4D938761.9000502@warmcat.com>
Mime-Version: 1.0 (iPhone Mail 8F190)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <4A4F3317-85A6-4059-B7AD-0DECF04A8296@gmail.com>
X-Mailer: iPhone Mail (8F190)
From: Brian McKelvey 
Date: Wed, 30 Mar 2011 13:47:41 -0700
To: Andy Green 
Cc: "hybi@ietf.org" 
Subject: Re: [hybi] Regarding "what parts of a frame should be masked"
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2011 20:46:11 -0000

Yeah.  As I've stated before, I'm strongly in favor of masking only the payl=
oad.

Relatedly, as others have also discovered, while implementing the deflate-st=
ream extension in my client, it became obvious that having a separate and ra=
ndom masking key for each frame drastically reduces the effectiveness of the=
 deflate-stream extension.  Has anyone given much thought to a deflate exten=
sion that operates on the data before masking?  That would allow us to use a=
 larger sliding window and substantially improve the compression ratio on a l=
arge class of data.  Libwebsockets for example uses an 8-bit window size, wh=
ich is pretty limited compared to the zlib default, but that makes sense giv=
en that none of the data from previous frames is likely to be usable in a la=
rger window because of the masking.  I seem to recall some discussion of thi=
s before but my memory is a bit fuzzy.  (as an interesting implementation no=
te, java's JZlib and subsequently the AS3 port as3zlib have a minimum allowe=
d window size of 9 for deflate, not 8 as in C zlib)

Brian

Sent from my iPhone

On Mar 30, 2011, at 12:41 PM, Andy Green  wrote:

> On 03/30/2011 08:16 PM, Somebody in the thread at some point said:
>> Hello everyone,
>>=20
>> in the HYBI session yesterday, there was a discussion about whether the
>> whole part of a WS frame should be masked or only payload and extension
>> data. The question was then moved to the mailing list.
>> I'm a CS student who is following this list out of interest (so please
>> forgive me if I say something stupid - I'll try not to :) ) and I
>> started roughly implementing the current draft to play around with the
>> technology.
>>=20
>> I noticed that implementing the masking becomes somewhat easier if the
>> length field is not masked. Because the masking key changes with each
>> frame, you obviously need to know the length of the frame before you can
>> unmask anything past the header. If the header (particularly the length
>> field) is masked as well, this means you need a separate unmasking
>> routine for the header. In contrast, if the length is unmasked, you can
>> simply read the whole frame into a buffer and then unmask it in one go.
>>=20
>> Both options are definitely "I can live with it". However, since there
>> didn't seem to be any strong points for or against either option in the
>> meeting, I'd like to give implementation complexity as an argument in
>> favour of "don't mask the header".
>=20
> I agree with you.
>=20
> It's worth reviewing this thread from 8th March
>=20
> http://www.ietf.org/mail-archive/web/hybi/current/msg06796.html
>=20
> which clearly sets out that and other views so you can understand the envi=
ronment around the issue as well as the issue itself.
>=20
> -Andy
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi

From jat@google.com  Wed Mar 30 13:57:09 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81CA33A6BC9 for ; Wed, 30 Mar 2011 13:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.64
X-Spam-Level: 
X-Spam-Status: No, score=-105.64 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fad8nI+6B87A for ; Wed, 30 Mar 2011 13:57:08 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 6D0C53A68FA for ; Wed, 30 Mar 2011 13:57:08 -0700 (PDT)
Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p2UKwkCC019374 for ; Wed, 30 Mar 2011 13:58:47 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301518727; bh=SqdjuHUdT5h9HLAWbKBC39Mt2Zo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=fEtretw6tFpxmZh2xyqbOxH4hx1VrauVFNjGYewdpCuyHlVgu1DqbNCKuVyGTOiOK YbbAZRxw/1xfL4HPkVyPg==
Received: from yxe1 (yxe1.prod.google.com [10.190.2.1]) by hpaq2.eem.corp.google.com with ESMTP id p2UKwin4008001 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 30 Mar 2011 13:58:45 -0700
Received: by yxe1 with SMTP id 1so879622yxe.39 for ; Wed, 30 Mar 2011 13:58:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0+G0UXOSamp7ND0r/GUvRWx7cR3oeograXgw/WMvJq8=; b=F7iHXt99t3Yb4z8AnF4m2/R3BYV3QxgykkswHXIxmQyoCfHzSeFTSpYpkgsTwJYpOL zWPF1i5W9sD60U4zv5hw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=BhTIkPrENCN0eijr/L/IU9vR2La7V/DTz4YR0rtyS2ZiUATbMW3O3O8ArmUK0bmJQE R2naXSSwtyGNGk6E4L/w==
Received: by 10.150.61.9 with SMTP id j9mr2010348yba.238.1301518724171; Wed, 30 Mar 2011 13:58:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.200.16 with HTTP; Wed, 30 Mar 2011 13:58:23 -0700 (PDT)
In-Reply-To: <4A4F3317-85A6-4059-B7AD-0DECF04A8296@gmail.com>
References: <4D93818C.8030702@gmail.com> <4D938761.9000502@warmcat.com> <4A4F3317-85A6-4059-B7AD-0DECF04A8296@gmail.com>
From: John Tamplin 
Date: Wed, 30 Mar 2011 16:58:23 -0400
Message-ID: 
To: Brian McKelvey 
Content-Type: multipart/alternative; boundary=000e0cd4c0e0390708049fb9713a
X-System-Of-Record: true
Cc: "hybi@ietf.org" 
Subject: Re: [hybi] Regarding "what parts of a frame should be masked"
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2011 20:57:09 -0000

--000e0cd4c0e0390708049fb9713a
Content-Type: text/plain; charset=UTF-8

On Wed, Mar 30, 2011 at 4:47 PM, Brian McKelvey wrote:

> Relatedly, as others have also discovered, while implementing the
> deflate-stream extension in my client, it became obvious that having a
> separate and random masking key for each frame drastically reduces the
> effectiveness of the deflate-stream extension.  Has anyone given much
> thought to a deflate extension that operates on the data before masking?
>  That would allow us to use a larger sliding window and substantially
> improve the compression ratio on a large class of data.  Libwebsockets for
> example uses an 8-bit window size, which is pretty limited compared to the
> zlib default, but that makes sense given that none of the data from previous
> frames is likely to be usable in a larger window because of the masking.  I
> seem to recall some discussion of this before but my memory is a bit fuzzy.
>  (as an interesting implementation note, java's JZlib and subsequently the
> AS3 port as3zlib have a minimum allowed window size of 9 for deflate, not 8
> as in C zlib)
>

Yes, there were discussions of better compression algorithms --
"deflate-stream" was included as a better-than-nothing case nobody objected
to that also served as an example extension.  However, I don't think
anything else is going to happen before the spec is finished, so other
compression schemes will be extensions defined later.

Personally, I think an effective compression scheme has to include some way
of not compressing incompressible data, which means it has to be on a
per-message basis (however, hopefully you would maintain compression state
across the stream) that would avoid framing data cluttering up the
compression dictionary.  There also needs to be consideration of memory
requirements on the server, which means restricting the compression
parameter choices on the client so the server doesn't have to keep large
compression state for each of many simultaneous connections.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--000e0cd4c0e0390708049fb9713a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Wed, Mar 30, 2011 at 4:47 PM, Brian McKelvey =
<theturtle32@=
gmail.com> wrote:


Relatedly, as others have also discovered, while implementing the deflate-s=
tream extension in my client, it became obvious that having a separate and =
random masking key for each frame drastically reduces the effectiveness of =
the deflate-stream extension. =C2=A0Has anyone given much thought to a defl=
ate extension that operates on the data before masking? =C2=A0That would al=
low us to use a larger sliding window and substantially improve the compres=
sion ratio on a large class of data. =C2=A0Libwebsockets for example uses a=
n 8-bit window size, which is pretty limited compared to the zlib default, =
but that makes sense given that none of the data from previous frames is li=
kely to be usable in a larger window because of the masking. =C2=A0I seem t=
o recall some discussion of this before but my memory is a bit fuzzy. =C2=
=A0(as an interesting implementation note, java's JZlib and subsequentl=
y the AS3 port as3zlib have a minimum allowed window size of 9 for deflate,=
 not 8 as in C zlib)




Yes, there were discussions of better comp=
ression algorithms -- "deflate-stream" was included as a better-t=
han-nothing case nobody objected to that also served as an example extensio=
n. =C2=A0However, I don't think anything else is going to happen before=
 the spec is finished, so other compression schemes will be extensions defi=
ned later.




Personally, I think an effective compression scheme has=
 to include some way of not compressing incompressible data, which means it=
 has to be on a per-message basis (however, hopefully you would maintain co=
mpression state across the stream) that would avoid framing data cluttering=
 up the compression dictionary. =C2=A0There also needs to be consideration =
of memory requirements on the server, which means restricting the compressi=
on parameter choices on the client so the server doesn't have to keep l=
arge compression state for each of many simultaneous connections.




-- 
John A. Tamplin
Software Engineer (GWT), Google


--000e0cd4c0e0390708049fb9713a--

From gregw@intalio.com  Wed Mar 30 15:07:51 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525F73A6BDD for ; Wed, 30 Mar 2011 15:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.857
X-Spam-Level: 
X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBy+l6SzuJDZ for ; Wed, 30 Mar 2011 15:07:50 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 455593A6BDB for ; Wed, 30 Mar 2011 15:07:50 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1657906vxg.31 for ; Wed, 30 Mar 2011 15:09:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.18.102 with SMTP id v6mr2437228vdd.224.1301522969075; Wed, 30 Mar 2011 15:09:29 -0700 (PDT)
Received: by 10.52.155.71 with HTTP; Wed, 30 Mar 2011 15:09:29 -0700 (PDT)
In-Reply-To: <4A4F3317-85A6-4059-B7AD-0DECF04A8296@gmail.com>
References: <4D93818C.8030702@gmail.com> <4D938761.9000502@warmcat.com> <4A4F3317-85A6-4059-B7AD-0DECF04A8296@gmail.com>
Date: Thu, 31 Mar 2011 09:09:29 +1100
Message-ID: 
From: Greg Wilkins 
To: Brian McKelvey 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" 
Subject: Re: [hybi] Regarding "what parts of a frame should be masked"
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2011 22:07:51 -0000

Brian,

This is a good reason that masking should be treated as a mandatory
extension applied only to the payload.
As an extension, it could be ordered against other extensions so we
could have per frame compression applied to the payload before masking
is applied.

regards



On 31 March 2011 07:47, Brian McKelvey  wrote:
> Yeah. =A0As I've stated before, I'm strongly in favor of masking only the=
 payload.
>
> Relatedly, as others have also discovered, while implementing the deflate=
-stream extension in my client, it became obvious that having a separate an=
d random masking key for each frame drastically reduces the effectiveness o=
f the deflate-stream extension. =A0Has anyone given much thought to a defla=
te extension that operates on the data before masking? =A0That would allow =
us to use a larger sliding window and substantially improve the compression=
 ratio on a large class of data. =A0Libwebsockets for example uses an 8-bit=
 window size, which is pretty limited compared to the zlib default, but tha=
t makes sense given that none of the data from previous frames is likely to=
 be usable in a larger window because of the masking. =A0I seem to recall s=
ome discussion of this before but my memory is a bit fuzzy. =A0(as an inter=
esting implementation note, java's JZlib and subsequently the AS3 port as3z=
lib have a minimum allowed window size of 9 for deflate, not 8 as in C zlib=
)
>
> Brian
>
> Sent from my iPhone
>
> On Mar 30, 2011, at 12:41 PM, Andy Green  wrote:
>
>> On 03/30/2011 08:16 PM, Somebody in the thread at some point said:
>>> Hello everyone,
>>>
>>> in the HYBI session yesterday, there was a discussion about whether the
>>> whole part of a WS frame should be masked or only payload and extension
>>> data. The question was then moved to the mailing list.
>>> I'm a CS student who is following this list out of interest (so please
>>> forgive me if I say something stupid - I'll try not to :) ) and I
>>> started roughly implementing the current draft to play around with the
>>> technology.
>>>
>>> I noticed that implementing the masking becomes somewhat easier if the
>>> length field is not masked. Because the masking key changes with each
>>> frame, you obviously need to know the length of the frame before you ca=
n
>>> unmask anything past the header. If the header (particularly the length
>>> field) is masked as well, this means you need a separate unmasking
>>> routine for the header. In contrast, if the length is unmasked, you can
>>> simply read the whole frame into a buffer and then unmask it in one go.
>>>
>>> Both options are definitely "I can live with it". However, since there
>>> didn't seem to be any strong points for or against either option in the
>>> meeting, I'd like to give implementation complexity as an argument in
>>> favour of "don't mask the header".
>>
>> I agree with you.
>>
>> It's worth reviewing this thread from 8th March
>>
>> http://www.ietf.org/mail-archive/web/hybi/current/msg06796.html
>>
>> which clearly sets out that and other views so you can understand the en=
vironment around the issue as well as the issue itself.
>>
>> -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
>

From derhoermi@gmx.net  Wed Mar 30 15:12:56 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092203A6BDE for ; Wed, 30 Mar 2011 15:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level: 
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9LscXWCr6Sg for ; Wed, 30 Mar 2011 15:12:55 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 855D43A6BDD for ; Wed, 30 Mar 2011 15:12:53 -0700 (PDT)
Received: (qmail invoked by alias); 30 Mar 2011 22:14:31 -0000
Received: from dslb-094-222-129-148.pools.arcor-ip.net (EHLO HIVE) [94.222.129.148] by mail.gmx.net (mp066) with SMTP; 31 Mar 2011 00:14:31 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1/fk51fEmXfEwoLtbMmdUmwCpgZNjwcN9oyYJMdW5 zFZWFIAmtdTx6k
From: Bjoern Hoehrmann 
To: John Tamplin 
Date: Thu, 31 Mar 2011 00:14:40 +0200
Message-ID: <0h97p69lv0b2almdkk2rnpbtpasf5lvq2b@hive.bjoern.hoehrmann.de>
References: <4D93818C.8030702@gmail.com> <4D938761.9000502@warmcat.com> <4A4F3317-85A6-4059-B7AD-0DECF04A8296@gmail.com> 
In-Reply-To: 
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "hybi@ietf.org" 
Subject: Re: [hybi] Regarding "what parts of a frame should be masked"
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2011 22:12:56 -0000

* John Tamplin wrote:
>Personally, I think an effective compression scheme has to include some way
>of not compressing incompressible data, which means it has to be on a
>per-message basis (however, hopefully you would maintain compression state
>across the stream) that would avoid framing data cluttering up the
>compression dictionary.

Could you elaborate on this problem? A deflate stream, whether in a gzip
or zlib container or not, is composed of a number of blocks which an en-
coder can make up as it sees fit. There are three block types, one with
dynamic codes, one with pre-defined codes, and one using no compression;
whichever you choose, incompressible data is stored reasonably well; if
you make the worst possible encoder, there is a low maximum overhead of
somewhere around 15% as I understand it. If you want Deflate blocks and
Websocket frames to synchronize, things might be a bit worse, but in ge-
neral I am not sure I understand the problem here.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From theturtle32@gmail.com  Wed Mar 30 16:37:54 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832F828C0F8 for ; Wed, 30 Mar 2011 16:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.186
X-Spam-Level: 
X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.016,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0MlZpfzM65f for ; Wed, 30 Mar 2011 16:37:53 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id DF0D33A6A7B for ; Wed, 30 Mar 2011 16:37:52 -0700 (PDT)
Received: by iye19 with SMTP id 19so2031480iye.31 for ; Wed, 30 Mar 2011 16:39:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=WY1Kg5hOB4qkHL1dWkii8xjNRzs19zqqAZbnbAdBYIQ=; b=D9I24+80xpAS9FhdTgJbk1LJc1MISnBNkewT5VHbHp8wpUd6sec3iyBuRNDlo7lkHk fdjuaz1hn58wN26JNYysa226zDSTGlR+oOQYhGjLhtKAI/5kAZes5suQKEl8sx/7c7Em DPsdL8+X8Po25+sHqGsL7XtJPrQ/UVODuNiNI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=vdywvvZ8NIawp8n7OTbgHkDH6/DoHmo8yMOEpNCthEvT5foRis0ApK47bX+8QkUYN/ ZEJASKNkL83zLH8wcdnMaSn9Ysk0BgCXcqTtoioTuWm4OSpyew0J9MBMsV48yfYU31Xs v1YDFMat/+TRCf57EjcgcKqeub/cDSoeUaXig=
Received: by 10.42.130.130 with SMTP id v2mr2037700ics.233.1301528371937; Wed, 30 Mar 2011 16:39:31 -0700 (PDT)
Received: from [10.101.109.20] ([166.205.138.223]) by mx.google.com with ESMTPS id hc41sm327284ibb.30.2011.03.30.16.39.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 16:39:30 -0700 (PDT)
References: <4D93818C.8030702@gmail.com> <4D938761.9000502@warmcat.com> <4A4F3317-85A6-4059-B7AD-0DECF04A8296@gmail.com>  <0h97p69lv0b2almdkk2rnpbtpasf5lvq2b@hive.bjoern.hoehrmann.de>
In-Reply-To: <0h97p69lv0b2almdkk2rnpbtpasf5lvq2b@hive.bjoern.hoehrmann.de>
Mime-Version: 1.0 (iPhone Mail 8F190)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary=Apple-Mail-1--1048861786
Message-Id: 
X-Mailer: iPhone Mail (8F190)
From: Brian McKelvey 
Date: Wed, 30 Mar 2011 16:39:22 -0700
To: Hybi , Bjoern Hoehrmann 
Subject: Re: [hybi] Regarding "what parts of a frame should be masked"
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2011 23:37:54 -0000

--Apple-Mail-1--1048861786
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The problem is that the compression state, which is maintained across frames=
, is polluted with unusable data from previous frames.  It's unusable becaus=
e the per-frame masking Is applied before the deflate processor.  Because ev=
ery frame is obfuscated with a different key, the chances of being able to u=
se compression state from previous frames to help compress subsequent frames=
 are very low.

If the compression was applied to the payload data before masking, we would b=
e able to use a lot more data from previous frames in the compression.

I'm ok with leaving it as-is for the initial release and defining a new, mor=
e efficient compression extension in the future to alleviate this problem.  J=
ust wanted to see what others had thought about on the topic.

Also, this problem only applies to data sent client->server, since the serve=
r-sent data is not masked.  The only nit to pick there, as was mentioned, is=
 the framing header data cluttering up the compression state, but that's pro=
bably not a very big deal comparatively.

Brian

Sent from my iPhone

On Mar 30, 2011, at 3:14 PM, Bjoern Hoehrmann  wrote:

> * John Tamplin wrote:
>> Personally, I think an effective compression scheme has to include some w=
ay
>> of not compressing incompressible data, which means it has to be on a
>> per-message basis (however, hopefully you would maintain compression stat=
e
>> across the stream) that would avoid framing data cluttering up the
>> compression dictionary.
>=20
> Could you elaborate on this problem? A deflate stream, whether in a gzip
> or zlib container or not, is composed of a number of blocks which an en-
> coder can make up as it sees fit. There are three block types, one with
> dynamic codes, one with pre-defined codes, and one using no compression;
> whichever you choose, incompressible data is stored reasonably well; if
> you make the worst possible encoder, there is a low maximum overhead of
> somewhere around 15% as I understand it. If you want Deflate blocks and
> Websocket frames to synchronize, things might be a bit worse, but in ge-
> neral I am not sure I understand the problem here.
> --=20
> Bj=C3=B6rn H=C3=B6hrmann =C2=B7mailto:bjoern@hoehrmann.de =C2=B7http://bjo=
ern.hoehrmann.de
> Am Badedeich 7 =C2=B7 Telefon:+49(0)160/4415681 =C2=B7http://www.bjoernswo=
rld.de
> 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.we=
bsitedev.de/=20

--Apple-Mail-1--1048861786
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The problem is that t=
he compression state, which is maintained across frames, is polluted with un=
usable data from previous frames.  It's unusable because the per-frame m=
asking Is applied before the deflate processor.  Because every frame is=
 obfuscated with a different key, the chances of being able to use compressi=
on state from previous frames to help compress subsequent frames are very lo=
w.
=

If the compressio=
n was applied to the payload data before masking, we would be able to use a l=
ot more data from previous frames in the compression.
=

I'm ok with leaving it as-is for the initi=
al release and defining a new, more efficient compression extension in the f=
uture to alleviate this problem.  Just wanted to see what others had th=
ought about on the topic.

=
Also, this problem only applies to data sent client->server, since t=
he server-sent data is not masked.  The only nit to pick there, as was m=
entioned, is the framing header data cluttering up the compression state, bu=
t that's probably not a very big deal comparatively.
Brian

Sent from my iPhone

On Mar 30, 2011, at 3:14 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

* John Tamplin wrote:
Personally, I think an effective=
 compression scheme has to include some way
of not compressing incompress=
ible data, which means it has to be on a
per-message basis (however, hope=
fully you would maintain compression state
across the stream) that would a=
void framing data cluttering up the
compression dictionary.

Could you elaborate on this problem? A deflate stream, whether in a gzip=

or zlib container or not, is compos=
ed of a number of blocks which an en-
coder can make up as it sees fit. There are three block types, one with
dynamic codes, one with pre-defined cod=
es, and one using no compression;
wh=
ichever you choose, incompressible data is stored reasonably well; if=

you make the worst possible encoder, there=
 is a low maximum overhead of
somewh=
ere around 15% as I understand it. If you want Deflate blocks and
=

Websocket frames to synchronize, things might b=
e a bit worse, but in ge-
neral I am=
 not sure I understand the problem here.
-- 
Bj=C3=B6rn H=C3=B6hrman=
n =C2=B7mailto:bjoern@hoehrmann.de=
 =C2=B7http://bjoern.hoehrmann.de=

Am Badedeich 7 =C2=B7 Telefon:+49(0)160/44=
15681 =C2=B7http://www.bjoernswo=
rld.de
25899 Dageb=C3=BCll =C2=
=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 h=
ttp://www.websitedev.de/ 
=

--Apple-Mail-1--1048861786--

From duerst@it.aoyama.ac.jp  Wed Mar 30 17:39:10 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB24D3A67D3 for ; Wed, 30 Mar 2011 17:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.854
X-Spam-Level: 
X-Spam-Status: No, score=-99.854 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAAy9VgFDy5F for ; Wed, 30 Mar 2011 17:39:10 -0700 (PDT)
Received: from acintmta02.acbb.aoyama.ac.jp (acintmta02.acbb.aoyama.ac.jp [133.2.20.34]) by core3.amsl.com (Postfix) with ESMTP id CD40328C1B7 for ; Wed, 30 Mar 2011 17:39:08 -0700 (PDT)
Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta02.acbb.aoyama.ac.jp (secret/secret) with SMTP id p2V0efPc001275 for ; Thu, 31 Mar 2011 09:40:42 +0900
Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 2168_b12a_81b55cdc_5b2f_11e0_8a39_001d0969ab06; Thu, 31 Mar 2011 09:40:41 +0900
Received: from [IPv6:::1] ([133.2.210.1]:37532) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 31 Mar 2011 09:40:40 +0900
Message-ID: <4D93CD85.9000705@it.aoyama.ac.jp>
Date: Thu, 31 Mar 2011 09:40:37 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Brian McKelvey 
References: <4D93818C.8030702@gmail.com> <4D938761.9000502@warmcat.com>	<4A4F3317-85A6-4059-B7AD-0DECF04A8296@gmail.com>		<0h97p69lv0b2almdkk2rnpbtpasf5lvq2b@hive.bjoern.hoehrmann.de> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Hybi 
Subject: Re: [hybi] Regarding "what parts of a frame should be masked"
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2011 00:39:10 -0000

It's totally obvious that randomizing first and then trying to compress 
later is totally the wrong way round. I'm fine with doing it the right 
way in a second round if there are enough hooks in the current spec that 
it isn't impossible.

Regards,   Martin.

On 2011/03/31 8:39, Brian McKelvey wrote:
> The problem is that the compression state, which is maintained across frames, is polluted with unusable data from previous frames.  It's unusable because the per-frame masking Is applied before the deflate processor.  Because every frame is obfuscated with a different key, the chances of being able to use compression state from previous frames to help compress subsequent frames are very low.
>
> If the compression was applied to the payload data before masking, we would be able to use a lot more data from previous frames in the compression.
>
> I'm ok with leaving it as-is for the initial release and defining a new, more efficient compression extension in the future to alleviate this problem.  Just wanted to see what others had thought about on the topic.
>
> Also, this problem only applies to data sent client->server, since the server-sent data is not masked.  The only nit to pick there, as was mentioned, is the framing header data cluttering up the compression state, but that's probably not a very big deal comparatively.
>
> Brian

From mcmanus@ducksong.com  Wed Mar 30 23:22:29 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E1528C20C for ; Wed, 30 Mar 2011 23:22:29 -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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STg79yRTzpLr for ; Wed, 30 Mar 2011 23:22:24 -0700 (PDT)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id F07F728C1FE for ; Wed, 30 Mar 2011 23:22:22 -0700 (PDT)
Received: from dhcp-46a6.meeting.ietf.org (dhcp-46a6.meeting.ietf.org [130.129.70.166]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id A9D97102A9 for ; Thu, 31 Mar 2011 02:24:01 -0400 (EDT)
Message-ID: <4D941E00.6090207@ducksong.com>
Date: Thu, 31 Mar 2011 08:24:00 +0200
From: Patrick McManus 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: hybi@ietf.org
References: <4D93818C.8030702@gmail.com>	<4D938761.9000502@warmcat.com>	<4A4F3317-85A6-4059-B7AD-0DECF04A8296@gmail.com>		<0h97p69lv0b2almdkk2rnpbtpasf5lvq2b@hive.bjoern.hoehrmann.de>	 <4D93CD85.9000705@it.aoyama.ac.jp>
In-Reply-To: <4D93CD85.9000705@it.aoyama.ac.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [hybi] Regarding "what parts of a frame should be masked"
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2011 06:22:29 -0000

On 3/31/11 2:40 AM, "Martin J. Dürst" wrote:
> It's totally obvious that randomizing first and then trying to 
> compress later is totally the wrong way round. I'm fine with doing it 
> the right way in a second round if there are enough hooks in the 
> current spec that it isn't impossible.
we don't even need a second round of the whole protocol - just publish a 
doc for the local-compression extension and define it this other way. 
deflate-stream is just a (well known) extension negotiated at handshake 
time like every other potential extension.


From andy.warmcat.com@googlemail.com  Wed Mar 30 23:56:23 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146613A691A for ; Wed, 30 Mar 2011 23:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.622
X-Spam-Level: 
X-Spam-Status: No, score=-3.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhkOESvN6SCh for ; Wed, 30 Mar 2011 23:56:22 -0700 (PDT)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id D585A3A6837 for ; Wed, 30 Mar 2011 23:56:21 -0700 (PDT)
Received: by wwk4 with SMTP id 4so4858053wwk.1 for ; Wed, 30 Mar 2011 23:58:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JEYcC3gqNM7UclF2EH42VWrchhkL9Qh4DbwtD2EICm0=; b=VxuJTAffn12PC0FupnzzsrxjcpHsfTiGHzk30YaB5yheYq5urhnGdwJrb4aMB62NTc K4nHAp+yeCLzbHeelgMvwvbW3GDDKd+3K9CfiC6IUQQSOt9CUwDJD5k5Q4bRQg5YCF2+ bpoROAlXS+WuMZ+L0n5VBb1NSoOCnWEH0UZpU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=XwQu3tsdhr+SS0bWBQnKa2quWbak7tYdCIdaoP6myI2kqfX5qPjfYOQOWlpH8vjDbQ fn2TGJ1WtQRQ/HVbQ93xbI1ZKwRVzrwhOFyF0QUkSaOxY44RC1spaVoE5WJsLudMAgjm fHU4B0+PCCoHxkc0anFaUDeonU9n5fW03WsAw=
Received: by 10.216.143.88 with SMTP id k66mr1920679wej.15.1301554680684; Wed, 30 Mar 2011 23:58:00 -0700 (PDT)
Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id w25sm467656wbd.22.2011.03.30.23.57.58 (version=SSLv3 cipher=OTHER); Wed, 30 Mar 2011 23:57:58 -0700 (PDT)
Sender: Andy Green 
Message-ID: <4D9425F4.5010906@warmcat.com>
Date: Thu, 31 Mar 2011 07:57:56 +0100
From: Andy Green 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110310 Fedora/3.1.9-2.fc16 Thunderbird/3.1.9
MIME-Version: 1.0
To: Greg Wilkins 
References: <4D93818C.8030702@gmail.com>	<4D938761.9000502@warmcat.com>	<4A4F3317-85A6-4059-B7AD-0DECF04A8296@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" 
Subject: Re: [hybi] Regarding "what parts of a frame should be masked"
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2011 06:56:23 -0000

On 03/30/2011 11:09 PM, Somebody in the thread at some point said:

Hi -

> This is a good reason that masking should be treated as a mandatory
> extension applied only to the payload.
> As an extension, it could be ordered against other extensions so we
> could have per frame compression applied to the payload before masking
> is applied.

This is a very good point.  Architecturally, it would simplify the issue 
into just precedence between compression and masking extensions that 
otherwise are nicely contained in individual domain-specific extension code.

At the moment with masking not even subordinate to the framing action, 
it just blasts in there dumping keys and munging data right in the code 
that writes out frames.

-Andy

From julian.reschke@gmx.de  Thu Mar 31 02:23:54 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79ACA28C216 for ; Thu, 31 Mar 2011 02:23:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.054
X-Spam-Level: 
X-Spam-Status: No, score=-104.054 tagged_above=-999 required=5 tests=[AWL=-1.455, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXwYRSWro37a for ; Thu, 31 Mar 2011 02:23:50 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 0C4D628C23C for ; Thu, 31 Mar 2011 02:21:35 -0700 (PDT)
Received: (qmail invoked by alias); 31 Mar 2011 09:22:59 -0000
Received: from dhcp-536f.meeting.ietf.org (EHLO [130.129.83.111]) [130.129.83.111] by mail.gmx.net (mp006) with SMTP; 31 Mar 2011 11:22:59 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19Y7wpwrnpYB5VDLNqJi4+lmxboGzizEY9LBKFO30 Hf7RyIdNL+NdGB
Message-ID: <4D9447F0.4020302@gmx.de>
Date: Thu, 31 Mar 2011 11:22:56 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: "hybi@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Subject: [hybi] spec references (editorial issue)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2011 09:23:55 -0000

Hi,

I noticed yesterday that the spec claims that all references are 
normative. That may not really be the case.

Candidates to be labeled are:

    [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
               "Internationalizing Domain Names in Applications (IDNA)",
               RFC 3490, March 2003.

(why do we have a IDNA reference anyway?)

    [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
               Procedures for Message Header Fields", BCP 90, RFC 3864,
               September 2004.

    [WSAPI]    Hickson, I., "The Web Sockets API", August 2010,
               .

BR, Julian









From julian.reschke@gmx.de  Thu Mar 31 02:23:58 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252DF28C267 for ; Thu, 31 Mar 2011 02:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.932
X-Spam-Level: 
X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sGt8nMdaLQ0 for ; Thu, 31 Mar 2011 02:23:57 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 0CF8728C248 for ; Thu, 31 Mar 2011 02:22:53 -0700 (PDT)
Received: (qmail invoked by alias); 31 Mar 2011 09:24:15 -0000
Received: from dhcp-536f.meeting.ietf.org (EHLO [130.129.83.111]) [130.129.83.111] by mail.gmx.net (mp030) with SMTP; 31 Mar 2011 11:24:15 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+sBAxeaoCsLP1p+DKDzqS9QJmSrX8Rjo0PcnULOG ElwYvuYRVmKyb/
Message-ID: <4D94483A.3070309@gmx.de>
Date: Thu, 31 Mar 2011 11:24:10 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: "hybi@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Subject: [hybi] Section 3 (URIs)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2011 09:23:58 -0000

Hi,

I believe that most if not all this section can be removed.

Websocket URIs are URIs, and their parsing is defined in RFC 3986.

Best regards, Julian

From gezelter@rlgsc.com  Thu Mar 31 05:33:30 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4240E28C134 for ; Thu, 31 Mar 2011 05:33:30 -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=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boMZVBgZ1xM8 for ; Thu, 31 Mar 2011 05:33:29 -0700 (PDT)
Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.235]) by core3.amsl.com (Postfix) with SMTP id 26A5128C121 for ; Thu, 31 Mar 2011 05:33:28 -0700 (PDT)
Received: (qmail 18710 invoked from network); 31 Mar 2011 12:35:07 -0000
Received: from unknown (141.157.198.38) by p3plsmtpa07-06.prod.phx3.secureserver.net (173.201.192.235) with ESMTP; 31 Mar 2011 12:35:07 -0000
Message-ID: <4D9474F8.10509@rlgsc.com>
Date: Thu, 31 Mar 2011 07:35:04 -0500
From: Bob Gezelter 
Organization: Robert Gezelter Software Consultant
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: hybi@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [hybi] Compression/masking precedence
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: gezelter@rlgsc.com
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2011 12:33:30 -0000

Masking should always be the last stage. Compression of masked data is
almost invariably far less efficient than compression of plaintext followed
by masking/encryption.

Example:   A(0x41) A(0x41) A(0x41) A(0x41) A(0x41) A(0x41) A(0x41) A(0x41)
     Mask:    0x01    0x02    0x03    0x04    0x01    0x02    0x03    0x04

Masked Text: 0x40    0x43    0x42    0x45    0x40    0x43    0x42    0x45

Compressed Text: 8*"A"
Masked: no successive character repeats (0x40, "CBE", 0x40, "CBE")

PGP is an example of this in practice. The text is compressed, then encoded.
Another illustration of this is daily backup sets. Compressing an
uncompressed backup set is often highly effective. Encrypting the resulting
data set does not take more steps. Reversing the precedence (encrypting
first, then compressing) produces far less effective compression.

- Bob
+--------------------------------------------------------------------------+
| Robert "Bob" Gezelter                       E-Mail:  gezelter@rlgsc.com  |
| Robert Gezelter Software Consultant                                      |
| 35-20 167th Street, Suite 215               Fax:       (on Request)      |
| Flushing, New York  11358-1731                                           |
| United States of America                    http://www.rlgsc.com         |
+--------------------------------------------------------------------------+

From jat@google.com  Thu Mar 31 05:44:12 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE823A697B for ; Thu, 31 Mar 2011 05:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.932
X-Spam-Level: 
X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwwLbk2byALg for ; Thu, 31 Mar 2011 05:44:11 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E49CC3A6A2B for ; Thu, 31 Mar 2011 05:44:10 -0700 (PDT)
Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p2VCjn5q032546 for ; Thu, 31 Mar 2011 05:45:50 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301575550; bh=tXBjXX++Q6eLCj7fApAazAEmBVY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=RjhOHudR6ocS6nMs3qZ7ANFPUtfWEbGvvVsUnldCzpHEy3TacJNqgu4B8iFlpOEwM r8DX/7cgrqfbQUgeW7R+g==
Received: from gxk28 (gxk28.prod.google.com [10.202.11.28]) by hpaq1.eem.corp.google.com with ESMTP id p2VCjb2S029617 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 31 Mar 2011 05:45:48 -0700
Received: by gxk28 with SMTP id 28so1096988gxk.13 for ; Thu, 31 Mar 2011 05:45:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fE9ZCvO/3XM5wjNSo3pTZEGw3k4BfLhFlJ4P9N5Zl+A=; b=LfmxC8DUVSps7ipSalZdXASQLuuVsLRo8VC7i1o5B9/bexog+3ONgrpuwFisDk3ubO 3AfhlCKbGQ0Fig53JsTQ==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=eysSn+PTBuqiiCSX3Lewq5CdcW+OgkWkC8sk+6wHEhXYyZThcTXeJ7XMvKYzWx+P1B 9v5uYVxAvthekinrXIng==
Received: by 10.150.162.2 with SMTP id k2mr3209460ybe.10.1301575548117; Thu, 31 Mar 2011 05:45:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.200.16 with HTTP; Thu, 31 Mar 2011 05:45:28 -0700 (PDT)
In-Reply-To: <4D9474F8.10509@rlgsc.com>
References:  <4D9474F8.10509@rlgsc.com>
From: John Tamplin 
Date: Thu, 31 Mar 2011 08:45:28 -0400
Message-ID: 
To: gezelter@rlgsc.com
Content-Type: multipart/alternative; boundary=000e0cd60ae431a547049fc6ac0d
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Compression/masking precedence
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2011 12:44:12 -0000

--000e0cd60ae431a547049fc6ac0d
Content-Type: text/plain; charset=UTF-8

On Thu, Mar 31, 2011 at 8:35 AM, Bob Gezelter  wrote:

> Masking should always be the last stage. Compression of masked data is
> almost invariably far less efficient than compression of plaintext followed
> by masking/encryption.
>

Nobody is arguing with that.  However, masking must be done at the frame
level, and the current deflate-stream extension operates at the connection
level, simply because that was something nobody objected to.  I don't think
anybody thought deflate-stream was the ultimate compression algorithm - just
something "better than nothing" that could be added without much debate.

See a post I made last May about the impact of different ways of doing
compression, even on small binary messages like those from GwtQuake.  I
certainly intend to propose a new compression extension once we get the base
spec out the door.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--000e0cd60ae431a547049fc6ac0d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Thu, Mar 31, 2011 at 8:35 AM, Bob Gezelter <gezelter@rlgsc.co=
m> wrote:


Masking should always be the last stage. Compression of masked data is

almost invariably far less efficient than compression of plaintext followed=


by masking/encryption.

Nobody is arguin=
g with that. =C2=A0However, masking must be done at the frame level, and th=
e current deflate-stream extension operates at the connection level, simply=
 because that was something nobody objected to. =C2=A0I don't think any=
body thought deflate-stream was the ultimate compression algorithm - just s=
omething "better than nothing" that could be added without much d=
ebate.




See a post I made last May about the impact of differen=
t ways of doing compression, even on small binary messages like those from =
GwtQuake. =C2=A0I certainly intend to propose a new compression extension o=
nce we get the base spec out the door.=C2=A0




-- 
John A. Tamplin
Software Engineer (GWT), Google


--000e0cd60ae431a547049fc6ac0d--

From mcmanus@ducksong.com  Thu Mar 31 05:54:58 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9AA128C0F0 for ; Thu, 31 Mar 2011 05:54: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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ft9sVWoNzfHN for ; Thu, 31 Mar 2011 05:54:57 -0700 (PDT)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 1D49728C0DB for ; Thu, 31 Mar 2011 05:54:57 -0700 (PDT)
Received: from dhcp-411f.meeting.ietf.org (dhcp-411f.meeting.ietf.org [130.129.65.31]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 22F9010178 for ; Thu, 31 Mar 2011 08:56:36 -0400 (EDT)
Message-ID: <4D947A01.3050605@ducksong.com>
Date: Thu, 31 Mar 2011 14:56:33 +0200
From: Patrick McManus 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: hybi@ietf.org
References: 	<4D9474F8.10509@rlgsc.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000605070308020601010408"
Subject: Re: [hybi] Compression/masking precedence
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2011 12:54:58 -0000

This is a multi-part message in MIME format.
--------------000605070308020601010408
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 3/31/11 2:45 PM, John Tamplin wrote:
> On Thu, Mar 31, 2011 at 8:35 AM, Bob Gezelter  > wrote:
>
>     Masking should always be the last stage. Compression of masked data is
>     almost invariably far less efficient than compression of plaintext
>     followed
>     by masking/encryption.
>
>
> Nobody is arguing with that.  However, masking must be done at the 
> frame level, and the current deflate-stream extension operates at the 
> connection level, simply because that was something nobody objected 
> to.  I don't think anybody thought deflate-stream was the ultimate 
> compression algorithm - just something "better than nothing" that 
> could be added without much debate.
>
> See a post I made last May about the impact of different ways of doing 
> compression, even on small binary messages like those from GwtQuake. 
>  I certainly intend to propose a new compression extension once we get 
> the base spec out the door.
>
this is all true, but lets not leave people with the impression that 
deflate-stream has no uses at all.

It certainly will provide help for largish messages (the xor won't 
change the distribution of anything within the message in the way real 
crypto would) as well as most flowing in the server->client direction. 
Note I said help - not "optimally help". A fair number of use cases 
would fall under these descriptions.





--------------000605070308020601010408
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    On 3/31/11 2:45 PM, John Tamplin wrote:
    

      
On Thu, Mar 31, 2011 at 8:35 AM, Bob
        Gezelter <gezelter@rlgsc.com>
        wrote:

        

          Masking should always be the last stage. Compression of masked
          data is

          almost invariably far less efficient than compression of
          plaintext followed

          by masking/encryption.

        

        


        

        
Nobody is arguing with that.  However, masking must be done
          at the frame level, and the current deflate-stream extension
          operates at the connection level, simply because that was
          something nobody objected to.  I don't think anybody thought
          deflate-stream was the ultimate compression algorithm - just
          something "better than nothing" that could be added without
          much debate.

        


        

        
See a post I made last May about the impact of different
          ways of doing compression, even on small binary messages like
          those from GwtQuake.  I certainly intend to propose a new
          compression extension once we get the base spec out the door. 

      

      

    

    this is all true, but lets not leave people with the impression that
    deflate-stream has no uses at all.

    

    It certainly will provide help for largish messages (the xor won't
    change the distribution of anything within the message in the way
    real crypto would) as well as most flowing in the server->client
    direction. Note I said help - not "optimally help". A fair number of
    use cases would fall under these descriptions.

    

    

    

    

  


--------------000605070308020601010408--

From ibc@aliax.net  Thu Mar 31 11:11:40 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4333A6B31 for ; Thu, 31 Mar 2011 11:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.636
X-Spam-Level: 
X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihWBVRa-h4w4 for ; Thu, 31 Mar 2011 11:11:34 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 94D8F3A6B6A for ; Thu, 31 Mar 2011 11:11:32 -0700 (PDT)
Received: by qwg5 with SMTP id 5so1967269qwg.31 for ; Thu, 31 Mar 2011 11:13:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.179.203 with SMTP id br11mr2584077qab.197.1301595191651; Thu, 31 Mar 2011 11:13:11 -0700 (PDT)
Received: by 10.229.35.72 with HTTP; Thu, 31 Mar 2011 11:13:11 -0700 (PDT)
In-Reply-To: <4D94483A.3070309@gmx.de>
References: <4D94483A.3070309@gmx.de>
Date: Thu, 31 Mar 2011 20:13:11 +0200
Message-ID: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
To: Julian Reschke 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" 
Subject: Re: [hybi] Section 3 (URIs)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2011 18:11:41 -0000

2011/3/31 Julian Reschke :
> I believe that most if not all this section can be removed.
>
> Websocket URIs are URIs, and their parsing is defined in RFC 3986.

The problem is that first versions of websocket draft was written for
developers with no knowlegde at all about any other spec, neither
HTTP.

--=20
I=C3=B1aki Baz Castillo


From ietf@adambarth.com  Thu Mar 31 11:18:11 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D073A6B38 for ; Thu, 31 Mar 2011 11:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level: 
X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[AWL=0.182,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JINGNM2-uc-v for ; Thu, 31 Mar 2011 11:18:11 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id DD6FA3A6B6A for ; Thu, 31 Mar 2011 11:18:10 -0700 (PDT)
Received: by vws12 with SMTP id 12so2448947vws.31 for ; Thu, 31 Mar 2011 11:19:50 -0700 (PDT)
Received: by 10.52.77.33 with SMTP id p1mr93485vdw.135.1301595590353; Thu, 31 Mar 2011 11:19:50 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by mx.google.com with ESMTPS id eh10sm746809vbb.14.2011.03.31.11.19.48 (version=SSLv3 cipher=OTHER); Thu, 31 Mar 2011 11:19:49 -0700 (PDT)
Received: by qyk29 with SMTP id 29so3566032qyk.10 for ; Thu, 31 Mar 2011 11:19:48 -0700 (PDT)
Received: by 10.224.70.208 with SMTP id e16mr2407852qaj.314.1301595588224; Thu, 31 Mar 2011 11:19:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.89.83 with HTTP; Thu, 31 Mar 2011 11:19:18 -0700 (PDT)
In-Reply-To: 
References: 
From: Adam Barth 
Date: Thu, 31 Mar 2011 11:19:18 -0700
Message-ID: 
To: "ietf@meetecho.com" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: hybi@ietf.org
Subject: Re: [hybi] HYBI recording available
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2011 18:18:12 -0000

I was excited to watch this recording but then I was sad that doing so
required granting full access to my machine to your web site.  Why
can't you just play the video in a web browser as is common on the
Internet?

Adam


On Wed, Mar 30, 2011 at 10:48 AM, ietf@meetecho.com  wrote:
> Dear all,
>
> the full recording (synchronized video, audio, slides and jabber room)
> of yesterday's HYBI session is available at the following URL:
>
> http://ietf.conf.meetecho.com
>
> We apologize for the bad audio quality on the first 20 minutes of the
> recording.
> We were not able to attach to the main audio stream before that time (the
> first minutes are taken live from the room speakers).
>
> In case of problems with the playout, just drop an e-mail to
> ietf-support@meetecho.com.
>
> Cheers,
> Meetecho Team
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>

From w@1wt.eu  Thu Mar 31 11:33:18 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52E33A6B7C for ; Thu, 31 Mar 2011 11:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level: 
X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+qQ0CgieJlP for ; Thu, 31 Mar 2011 11:33:18 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id A6BE33A6AAB for ; Thu, 31 Mar 2011 11:33:17 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p2VIYpTI031024; Thu, 31 Mar 2011 20:34:51 +0200
Date: Thu, 31 Mar 2011 20:34:51 +0200
From: Willy Tarreau 
To: Adam Barth 
Message-ID: <20110331183451.GA31012@1wt.eu>
References:  
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org
Subject: Re: [hybi] HYBI recording available
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2011 18:33:18 -0000

On Thu, Mar 31, 2011 at 11:19:18AM -0700, Adam Barth wrote:
> I was excited to watch this recording but then I was sad that doing so
> required granting full access to my machine to your web site.  Why
> can't you just play the video in a web browser as is common on the
> Internet?

Ah now I understand why it required me to download a .jnlp file
which I supposed was for a plugin. I did not notice there was a
specific client.

I'm realizing that later there might exist a less demanding client
making use of WebSocket for the same service ;-)

Cheers,
Willy


From ietf@meetecho.com  Thu Mar 31 12:07:33 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F362C3A6BA7 for ; Thu, 31 Mar 2011 12:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMeO98pnSc8L for ; Thu, 31 Mar 2011 12:07:32 -0700 (PDT)
Received: from smtplq01.aruba.it (smtplq-out13.aruba.it [62.149.158.33]) by core3.amsl.com (Postfix) with SMTP id 6EF963A6B96 for ; Thu, 31 Mar 2011 12:07:31 -0700 (PDT)
Received: (qmail 21438 invoked by uid 89); 31 Mar 2011 19:09:09 -0000
Received: from unknown (HELO smtp1.aruba.it) (62.149.158.221) by smtplq01.aruba.it with SMTP; 31 Mar 2011 19:09:09 -0000
Received: (qmail 3657 invoked by uid 89); 31 Mar 2011 19:09:09 -0000
Received: from unknown (HELO lminiero-acer) (ietf@meetecho.com@130.129.21.22) by smtp1.ad.aruba.it with SMTP; 31 Mar 2011 19:09:09 -0000
Date: Thu, 31 Mar 2011 21:04:25 +0200
From: Lorenzo Miniero 
To: Willy Tarreau 
Message-ID: <20110331210425.66eda2eb@lminiero-acer>
In-Reply-To: <20110331183451.GA31012@1wt.eu>
References:   <20110331183451.GA31012@1wt.eu>
Organization: Meetecho
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Rating: smtp1.ad.aruba.it 1.6.2 0/1000/N
X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N
Cc: hybi@ietf.org
Subject: Re: [hybi] HYBI recording available
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2011 19:07:33 -0000

Dear Adam and Willy,

about the full access, that's a security policy notification that is common to all JNLP-based applications. Similar messages are also shown for applets, for instance. JNLP is just a simple way to get Java applications started from the network, taking care of library dependencies and the like automatically.

We can just reassure you that the only thing the application does is retrieve the SMIL description file, i.e. a standard way to describe a synchronized view of all the involved media, and in turn download the media content itself. After that, the playout starts allowing you to seek.

An ad-hoc player was needed since our approach towards the SMIL description at the moment slightly differs from the standard in a few parts: you can also try and directly play the SMIL file yourself using any compliant player (there are a few around), but the presentation may not be perfect.

For what concerns the WebSocket approach, we're actually already working on a completely web-based player of the recordings, which would exploit the same functionality already made available by the WebLite client (the one that was used to allow folks to attend IETF sessions using our system), but it isn't available yet.

Hoping this isn't a dealbreaker for you :)

Cheers,
Lorenzo


On Thu, 31 Mar 2011 20:34:51 +0200
Willy Tarreau  wrote:

> On Thu, Mar 31, 2011 at 11:19:18AM -0700, Adam Barth wrote:
> > I was excited to watch this recording but then I was sad that doing so
> > required granting full access to my machine to your web site.  Why
> > can't you just play the video in a web browser as is common on the
> > Internet?
> 
> Ah now I understand why it required me to download a .jnlp file
> which I supposed was for a plugin. I did not notice there was a
> specific client.
> 
> I'm realizing that later there might exist a less demanding client
> making use of WebSocket for the same service ;-)
> 
> Cheers,
> Willy
> 


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

From sm@resistor.net  Thu Mar 31 13:08:03 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5789F28C0FC for ; Thu, 31 Mar 2011 13:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.416
X-Spam-Level: 
X-Spam-Status: No, score=-102.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1wLiD3l7-Yt for ; Thu, 31 Mar 2011 13:07:59 -0700 (PDT)
Received: from mx.elandsys.com (eland-1-pt.tunnel.tserv15.lax1.ipv6.he.net [IPv6:2001:470:c:d43::2]) by core3.amsl.com (Postfix) with ESMTP id 5057828C0FB for ; Thu, 31 Mar 2011 13:07:59 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p2VK9UtX018405;  Thu, 31 Mar 2011 13:09:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1301602175; bh=0fxyGqEoCfYmBEOX6fwLbsBN31SPv53L0T1oBeYFnBk=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=Zguoq8sVyWpVB1A1yTLtnREk35wGlB2FTrPPP08UIU+OlFsE+eZkdV2nwOtBjyz6k bBsoTFcZmKvy2VpX066MwiRdEbaGxSpIJWoXMlScv8SQWSHrltIH3lUW75BwJ5CJ4x 2032H2VtviYYC99vXjuAhtRsSA1FluKp5Omow0i8=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1301602175; bh=0fxyGqEoCfYmBEOX6fwLbsBN31SPv53L0T1oBeYFnBk=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=DeLJ/AdLopRsgcL3IAXRnUKmIEck0a915IZoPV57m692pnT1NNbqRPOE+oUNFVSYH 3GU9u0D1MWzpnWXZXK/znTUEPjZlmG1Vr5bQLCt6pzat9BlTi6N6BaLLi4OXROxvye 1j040g3XSjrvb2wqdjRDUJCjZhuolWh5vtFGMqEY=
Message-Id: <6.2.5.6.2.20110331104448.094aaa08@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 31 Mar 2011 10:55:33 -0700
To: Julian Reschke 
From: SM 
In-Reply-To: <4D9447F0.4020302@gmx.de>
References: <4D9447F0.4020302@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: hybi@ietf.org
Subject: Re: [hybi] spec references (editorial issue)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2011 20:08:03 -0000

Hi Julian,
At 02:22 31-03-2011, Julian Reschke wrote:
>I noticed yesterday that the spec claims that all references are 
>normative. That may not really be the case.
>
>Candidates to be labeled are:
>
>    [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
>               "Internationalizing Domain Names in Applications (IDNA)",
>               RFC 3490, March 2003.
>
>(why do we have a IDNA reference anyway?)

There is a reference to RFC 3490 in the IANA Considerations 
section.  It could be Informative.

>    [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
>               Procedures for Message Header Fields", BCP 90, RFC 3864,
>               September 2004.

This could be informative.

>    [WSAPI]    Hickson, I., "The Web Sockets API", August 2010,
>               .

This can be informative as it is only referenced from the Background section.

Regards,
-sm 


From ietf@adambarth.com  Thu Mar 31 15:14:37 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6233628C122 for ; Thu, 31 Mar 2011 15:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level: 
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=0.179,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY8dOsjrHS+N for ; Thu, 31 Mar 2011 15:14:36 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 9DF123A69C7 for ; Thu, 31 Mar 2011 15:14:36 -0700 (PDT)
Received: by gyf3 with SMTP id 3so1321255gyf.31 for ; Thu, 31 Mar 2011 15:16:16 -0700 (PDT)
Received: by 10.236.78.102 with SMTP id f66mr55706yhe.264.1301609775982; Thu, 31 Mar 2011 15:16:15 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id 7sm793298yhl.19.2011.03.31.15.16.14 (version=SSLv3 cipher=OTHER); Thu, 31 Mar 2011 15:16:14 -0700 (PDT)
Received: by iye19 with SMTP id 19so3295610iye.31 for ; Thu, 31 Mar 2011 15:16:14 -0700 (PDT)
Received: by 10.42.97.69 with SMTP id m5mr3942991icn.116.1301609774139; Thu, 31 Mar 2011 15:16:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.133.200 with HTTP; Thu, 31 Mar 2011 15:15:44 -0700 (PDT)
In-Reply-To: <20110331210159.36555923@lminiero-acer>
References:   <20110331183451.GA31012@1wt.eu> <20110331210159.36555923@lminiero-acer>
From: Adam Barth 
Date: Thu, 31 Mar 2011 15:15:44 -0700
Message-ID: 
To: Lorenzo Miniero 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] HYBI recording available
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2011 22:14:37 -0000

It is a dealbreaker for me, but I look forward to being able to watch
the videos on your web site without needing to trust you with the
privilege to execute arbitrary code on my machine.

Adam


On Thu, Mar 31, 2011 at 12:01 PM, Lorenzo Miniero  wrote=
:
> Dear Adam and Willy,
>
> about the full access, that's a security policy notification that is comm=
on to all JNLP-based applications. Similar messages are also shown for appl=
ets, for instance. JNLP is just a simple way to get Java applications start=
ed from the network, taking care of library dependencies and the like autom=
atically.
>
> We can just reassure you that the only thing the application does is retr=
ieve the SMIL description file, i.e. a standard way to describe a synchroni=
zed view of all the involved media, and in turn download the media content =
itself. After that, the playout starts allowing you to seek.
>
> An ad-hoc player was needed since our approach towards the SMIL descripti=
on at the moment slightly differs from the standard in a few parts: you can=
 also try and directly play the SMIL file yourself using any compliant play=
er (there are a few around), but the presentation may not be perfect.
>
> For what concerns the WebSocket approach, we're actually already working =
on a completely web-based player of the recordings, which would exploit the=
 same functionality already made available by the WebLite client (the one t=
hat was used to allow folks to attend IETF sessions using our system), but =
it isn't available yet.
>
> Hoping this isn't a dealbreaker for you :)
>
> Cheers,
> Lorenzo
>
>
>
>
> On Thu, 31 Mar 2011 20:34:51 +0200
> Willy Tarreau  wrote:
>
>> On Thu, Mar 31, 2011 at 11:19:18AM -0700, Adam Barth wrote:
>> > I was excited to watch this recording but then I was sad that doing so
>> > required granting full access to my machine to your web site. =A0Why
>> > can't you just play the video in a web browser as is common on the
>> > Internet?
>>
>> Ah now I understand why it required me to download a .jnlp file
>> which I supposed was for a plugin. I did not notice there was a
>> specific client.
>>
>> I'm realizing that later there might exist a less demanding client
>> making use of WebSocket for the same service ;-)
>>
>> Cheers,
>> Willy
>>
>

From simone.bordet@gmail.com  Thu Mar 31 15:28:58 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B023A6BC0 for ; Thu, 31 Mar 2011 15:28:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sr9ZSppaBPiz for ; Thu, 31 Mar 2011 15:28:57 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 7A1733A698F for ; Thu, 31 Mar 2011 15:28:57 -0700 (PDT)
Received: by qwg5 with SMTP id 5so2119948qwg.31 for ; Thu, 31 Mar 2011 15:30:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HzfXqiidYqsGy8L9FOVkbnyanY9CAGiNdugo8Tmnlxg=; b=HE6lmga/YKAKnwMWL0KXB6Ili+Tl6gkVXL8FGjvtu9pn8GnT1WZn4WQt0eYjMIhfxW Hz+vbgO4LOaVhLI8mqmNxXdlZ46T+jQfFBP4cFMjlqvfGUl9f2bV/wczc01OKG0oXZ4U rucemjnz8yb0RDq3Gev9meZ5ZSLt7R0zc06gE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oUeWHfw3hak5sGN+mohwpzt8UAGxAWeSZ6J4loj1QRsgOlAtOyyaZBpc7UTuEpD3Mx XOV1IgGVYLBKoxd//GvZ11tcS7AANdjLTdmM+YbekVU3C7aF6cAjYSpmPeFJZVuQbPxD zNSShUUb52L+Ql5egHlNqxPpEOqUJhxqu7bV4=
MIME-Version: 1.0
Received: by 10.229.105.132 with SMTP id t4mr2828725qco.42.1301610636720; Thu, 31 Mar 2011 15:30:36 -0700 (PDT)
Received: by 10.229.66.70 with HTTP; Thu, 31 Mar 2011 15:30:36 -0700 (PDT)
In-Reply-To: <20110331210425.66eda2eb@lminiero-acer>
References:   <20110331183451.GA31012@1wt.eu> <20110331210425.66eda2eb@lminiero-acer>
Date: Fri, 1 Apr 2011 00:30:36 +0200
Message-ID: 
From: Simone Bordet 
To: Lorenzo Miniero 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] HYBI recording available
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2011 22:28:58 -0000

Hi,

On Thu, Mar 31, 2011 at 21:04, Lorenzo Miniero  wrote:
> Dear Adam and Willy,
>
> about the full access, that's a security policy notification that is comm=
on to all JNLP-based applications.

Not exactly true, as not all JNLP application needs
java.security.AllPermission to run.

> We can just reassure you that the only thing the application does is retr=
ieve the SMIL description file, i.e. a standard way to describe a synchroni=
zed view of all the involved media, and in turn download the media content =
itself. After that, the playout starts allowing you to seek.

The player uses native libraries, which requires all permissions, so
there is no easy way out (unless of course you change the player).

Would it be possible to convert the video to some other format that
only requires a browser to see, as per Adam's suggestion ?

> Hoping this isn't a dealbreaker for you :)

It is for me also. We're in 2011 and JNLP requiring AllPermission
looks soooo 2000s.

I could watch it in a virtual machine, but it's a lot more complicated
than it needs to.

Simon
--=20
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.=C2=A0=C2=A0 Victoria Livschi=
tz

From ietf@meetecho.com  Thu Mar 31 17:09:30 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75DB43A6BC6 for ; Thu, 31 Mar 2011 17:09:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.219
X-Spam-Level: 
X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[AWL=0.498,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQt8ZOwO3j87 for ; Thu, 31 Mar 2011 17:09:29 -0700 (PDT)
Received: from smtpw2.aruba.it (smtpa1.aruba.it [62.149.128.210]) by core3.amsl.com (Postfix) with SMTP id 2D8D33A6B5C for ; Thu, 31 Mar 2011 17:09:27 -0700 (PDT)
Received: (qmail 20280 invoked by uid 89); 1 Apr 2011 00:11:06 -0000
Received: from unknown (HELO aruba.it) (62.149.158.91) by smtpw2.ad.aruba.it with SMTP; 1 Apr 2011 00:11:06 -0000
Date: Fri,  1 Apr 2011 02:11:06 +0200
Message-Id: 
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: multipart/alternative; boundary="_=__=_XaM3_.1301616666.2A.106987.42.32455.52.42.007.542204631"
From: "ietf@meetecho.com" 
To: simone.bordet@gmail.com
X-XaM3-API-Version: V3(R2)
X-SenderIP: 193.179.131.74
X-Spam-Rating: smtpw2.ad.aruba.it 1.6.2 0/1000/N
Cc: info@meetecho.com, hybi@ietf.org
Subject: Re: [hybi] HYBI recording available
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Apr 2011 00:09:30 -0000

--_=__=_XaM3_.1301616666.2A.106987.42.32455.52.42.007.542204631
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi guys,=0A=0Awe answer your questions once and for all (hopefully ;-)) b=
elow. First =0Aof all, I'm afraid not all of you realized that the record=
ings are not =0A"just" videos. Indeed, they are multimedia assets properl=
y assembled =0A(and synchronized) through a SMIL (http://www.w3.org/Audio=
Video/) file. =0AAs an example, here is the .smil representation of the H=
yBi recording:=0A=0Ahttp://meetecho-ietf.comics.unina.it/recordings/hybi/=
recording.smil=0A=0AAs you can easily recognize, it contains references t=
o slide images, =0Achat log (as a textstream), plus the movie file contai=
ning both audio =0Aand video (http://143.225.229.137/recordings/hybi/vide=
o.mov). If you are=0A familiar with smil (and I assume you are, since you=
 all live in 2011), =0Ayou can just take the mentioned file and play with=
 it in order to: (i) =0Aeither let it work with your favorite smil player=
; (ii) or patiently =0Adownload all of the referenced resources (with you=
r favorite software) =0Aand enjoy them separately. =0A=0AIn order to faci=
litate your work, we have put on-line, in the downloads =0Asection on www=
.meetecho.com: (i) a ready-to-go java application that you=0A can downloa=
d on your computer and which can be fed with the smil file =0Ain order to=
 play out the recordings (it is actually the scary software =0Awe launch =
when you click on the on-line recording link); (ii) the source=0A code of=
 the mentioned scary application, which you can freely download =0Aand mo=
dify in order to both double-check its correctness and improve it.=0A In =
the second case (i.e. if you happen to improve it) we would be glad =0Ato=
 receive from you the updated version. Please keep in mind that the =0Aap=
plication requires that you have Java Media Framework installed on =0Ayou=
r PC.=0A=0AJust one thing: www.meetecho.com requires that you register be=
fore =0Aallowing you to download our software. Registration is just for o=
ur logs=0A and we don't sell private information to third parties. If it =
is too =0Amuch for you, just throw in the towel ;-).=0A=0AHope this helps=
,=0A=0AThe Meetecho Team=0ADa: "Simone Bordet" simone.bordet@gmail.com=0A=
A: "Lorenzo Miniero" ietf@meetecho.com=0ACc: "Willy Tarreau" w@1wt.eu, hy=
bi@ietf.org=0AData: Fri, 1 Apr 2011 00:30:36 +0200=0AOggetto: Re: [hybi] =
HYBI recording available=0A=0A> Hi,=0A> =0A> On Thu, Mar 31, 2011 at 21:0=
4, Lorenzo Miniero  wrote:=0A> > Dear Adam and Willy,=0A> >=0A> > about t=
he full access, that's a security policy notification that is common to a=
ll JNLP-based applications.=0A> =0A> Not exactly true, as not all JNLP ap=
plication needs=0A> java.security.AllPermission to run.=0A> =0A> > We can=
 just reassure you that the only thing the application does is retrieve t=
he SMIL description file, i.e. a standard way to describe a synchronized =
view of all the involved media, and in turn download the media content it=
self. After that, the playout starts allowing you to seek.=0A> =0A> The p=
layer uses native libraries, which requires all permissions, so=0A> there=
 is no easy way out (unless of course you change the player).=0A> =0A> Wo=
uld it be possible to convert the video to some other format that=0A> onl=
y requires a browser to see, as per Adam's suggestion ?=0A> =0A> > Hoping=
 this isn't a dealbreaker for you :)=0A> =0A> It is for me also. We're in=
 2011 and JNLP requiring AllPermission=0A> looks soooo 2000s.=0A> =0A> I =
could watch it in a virtual machine, but it's a lot more complicated=0A> =
than it needs to.=0A> =0A> Simon=0A> -- =0A> http://bordet.blogspot.com=0A=
> ---=0A> Finally, no matter how good the architecture and design are,=0A=
> to deliver bug-free software with optimal performance and reliability,=0A=
> the implementation technique must be flawless.=C2=A0=C2=A0 Victoria Liv=
schitz

--_=__=_XaM3_.1301616666.2A.106987.42.32455.52.42.007.542204631
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=0A
=0A
Hi guys,
=0A
=0Awe answer your questions once=
 and for all (hopefully ;-)) below. First =0Aof all, I'm afraid not all o=
f you realized that the recordings are not =0A"just" videos. Indeed, they=
 are multimedia assets properly assembled =0A(and synchronized) through a=
 SMIL (http://www.w3.org/AudioVideo/) file. =0AAs an example, here is the=
 .smil representation of the HyBi recording:
=0A
=0Ahttp://m=
eetecho-ietf.comics.unina.it/recordings/hybi/recording.smil
=0A=0AAs you can easily recognize, it contains references to slide images, =
=0Achat log (as a textstream), plus the movie file containing both audio =
=0Aand video (http://143.225.229.137/recordings/hybi/video.mov). If you a=
re=0A familiar with smil (and I assume you are, since you all live in 201=
1), =0Ayou can just take the mentioned file and play with it in order to:=
 (i) =0Aeither let it work with your favorite smil player; (ii) or patien=
tly =0Adownload all of the referenced resources (with your favorite softw=
are) =0Aand enjoy them separately. 
=0A
=0AIn order to facilitate y=
our work, we have put on-line, in the downloads =0Asection on www.meetech=
o.com: (i) a ready-to-go java application that you=0A can download on you=
r computer and which can be fed with the smil file =0Ain order to play ou=
t the recordings (it is actually the scary software =0Awe launch when you=
 click on the on-line recording link); (ii) the source=0A code of the men=
tioned scary application, which you can freely download =0Aand modify in =
order to both double-check its correctness and improve it.=0A In the seco=
nd case (i.e. if you happen to improve it) we would be glad =0Ato receive=
 from you the updated version. Please keep in mind that the =0Aapplicatio=
n requires that you have Java Media Framework installed on =0Ayour PC.=0A
=0AJust one thing: www.meetecho.com requires that you register be=
fore =0Aallowing you to download our software. Registration is just for o=
ur logs=0A and we don't sell private information to third parties. If it =
is too =0Amuch for you, just throw in the towel ;-).
=0A
=0AHope th=
is helps,
=0A
=0AThe Meetecho Team

=0A
Da: "Simone Bordet" simone.bordet@gmail.com
=
=0A
A: "Lorenzo Miniero" ietf@meete=
cho.com
=0A
Cc: "Willy =
Tarreau" w@1wt.eu, hybi@ietf.org
=0A
Data: Fri, 1 Apr 2011 00:30:36 +0200
=0A
: Re: [hybi] HYBI recording availa=
ble
=0A
=0A
> Hi,
> 
> On=
 Thu, Mar 31, 2011 at 21:04, Lorenzo Miniero  wrote:
> > Dear Adam and Willy,
>=
; >
> > about the full access, that's a security polic=
y notification that is common to all JNLP-based applications.
&=
gt; 
> Not exactly true, as not all JNLP application needs
> java.security.AllPermission to run.
> 
> > We can just reassure you that the only thing the application=
 does is retrieve the SMIL description file, i.e. a standard way to descr=
ibe a synchronized view of all the involved media, and in turn download t=
he media content itself. After that, the playout starts allowing you to s=
eek.
> 
> The player uses native libraries, whi=
ch requires all permissions, so
> there is no easy way out (=
unless of course you change the player).
> 
> W=
ould it be possible to convert the video to some other format that
<=
div>> only requires a browser to see, as per Adam's suggestion ?
=

> 
> > Hoping this isn't a dealbreaker for you :)=

> 
> It is for me also. We're in 2011 and JNLP=
 requiring AllPermission
> looks soooo 2000s.
>=
 
> I could watch it in a virtual machine, but it's a lot mo=
re complicated
> than it needs to.
> 
> Simon
> -- 
> http://bordet.blogspot.com<=
/div>
> ---
> Finally, no matter how good the archite=
cture and design are,
> to deliver bug-free software with op=
timal performance and reliability,
> the implementation tech=
nique must be flawless.   Victoria Livschitz
=0A=0A

--_=__=_XaM3_.1301616666.2A.106987.42.32455.52.42.007.542204631--


From ietf@adambarth.com  Thu Mar 31 17:45:30 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780403A6B74 for ; Thu, 31 Mar 2011 17:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level: 
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVSZKlmj4Adx for ; Thu, 31 Mar 2011 17:45:29 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 1BF2D3A6B65 for ; Thu, 31 Mar 2011 17:45:29 -0700 (PDT)
Received: by yic13 with SMTP id 13so1371030yic.31 for ; Thu, 31 Mar 2011 17:47:08 -0700 (PDT)
Received: by 10.236.189.71 with SMTP id b47mr2385495yhn.176.1301618828639; Thu, 31 Mar 2011 17:47:08 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id 51sm857384yha.58.2011.03.31.17.47.07 (version=SSLv3 cipher=OTHER); Thu, 31 Mar 2011 17:47:07 -0700 (PDT)
Received: by iwn39 with SMTP id 39so3405421iwn.31 for ; Thu, 31 Mar 2011 17:47:07 -0700 (PDT)
Received: by 10.42.97.69 with SMTP id m5mr4128154icn.116.1301618827066; Thu, 31 Mar 2011 17:47:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.133.200 with HTTP; Thu, 31 Mar 2011 17:46:36 -0700 (PDT)
In-Reply-To: 
References: 
From: Adam Barth 
Date: Thu, 31 Mar 2011 17:46:36 -0700
Message-ID: 
To: "ietf@meetecho.com" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: info@meetecho.com, hybi@ietf.org
Subject: Re: [hybi] HYBI recording available
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Apr 2011 00:45:30 -0000

That's all very nice, but I'm not going to audit your Java source code
in order to watch this content.  However, I would very much like to
watch the video in my browser.  I doubt I'm the only one.

Kind regards,
Adam


On Thu, Mar 31, 2011 at 5:11 PM, ietf@meetecho.com  wrot=
e:
> Hi guys,
>
> we answer your questions once and for all (hopefully ;-)) below. First of
> all, I'm afraid not all of you realized that the recordings are not "just=
"
> videos. Indeed, they are multimedia assets properly assembled (and
> synchronized) through a SMIL (http://www.w3.org/AudioVideo/) file. As an
> example, here is the .smil representation of the HyBi recording:
>
> http://meetecho-ietf.comics.unina.it/recordings/hybi/recording.smil
>
> As you can easily recognize, it contains references to slide images, chat
> log (as a textstream), plus the movie file containing both audio and vide=
o
> (http://143.225.229.137/recordings/hybi/video.mov). If you are familiar w=
ith
> smil (and I assume you are, since you all live in 2011), you can just tak=
e
> the mentioned file and play with it in order to: (i) either let it work w=
ith
> your favorite smil player; (ii) or patiently download all of the referenc=
ed
> resources (with your favorite software) and enjoy them separately.
>
> In order to facilitate your work, we have put on-line, in the downloads
> section on www.meetecho.com: (i) a ready-to-go java application that you =
can
> download on your computer and which can be fed with the smil file in orde=
r
> to play out the recordings (it is actually the scary software we launch w=
hen
> you click on the on-line recording link); (ii) the source code of the
> mentioned scary application, which you can freely download and modify in
> order to both double-check its correctness and improve it. In the second
> case (i.e. if you happen to improve it) we would be glad to receive from =
you
> the updated version. Please keep in mind that the application requires th=
at
> you have Java Media Framework installed on your PC.
>
> Just one thing: www.meetecho.com requires that you register before allowi=
ng
> you to download our software. Registration is just for our logs and we do=
n't
> sell private information to third parties. If it is too much for you, jus=
t
> throw in the towel ;-).
>
> Hope this helps,
>
> The Meetecho Team
>
> Da: "Simone Bordet" simone.bordet@gmail.com
> A: "Lorenzo Miniero" ietf@meetecho.com
> Cc: "Willy Tarreau" w@1wt.eu, hybi@ietf.org
> Data: Fri, 1 Apr 2011 00:30:36 +0200
> Oggetto: Re: [hybi] HYBI recording available
>> Hi,
>>
>> On Thu, Mar 31, 2011 at 21:04, Lorenzo Miniero wrote:
>> > Dear Adam and Willy,
>> >
>> > about the full access, that's a security policy notification that is
>> > common to all JNLP-based applications.
>>
>> Not exactly true, as not all JNLP application needs
>> java.security.AllPermission to run.
>>
>> > We can just reassure you that the only thing the application does is
>> > retrieve the SMIL description file, i.e. a standard way to describe a
>> > synchronized view of all the involved media, and in turn download the =
media
>> > content itself. After that, the playout starts allowing you to seek.
>>
>> The player uses native libraries, which requires all permissions, so
>> there is no easy way out (unless of course you change the player).
>>
>> Would it be possible to convert the video to some other format that
>> only requires a browser to see, as per Adam's suggestion ?
>>
>> > Hoping this isn't a dealbreaker for you :)
>>
>> It is for me also. We're in 2011 and JNLP requiring AllPermission
>> looks soooo 2000s.
>>
>> I could watch it in a virtual machine, but it's a lot more complicated
>> than it needs to.
>>
>> Simon
>> --
>> http://bordet.blogspot.com
>> ---
>> Finally, no matter how good the architecture and design are,
>> to deliver bug-free software with optimal performance and reliability,
>> the implementation technique must be flawless.=A0=A0 Victoria Livschitz
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>

From dendicott@gmail.com  Thu Mar 31 19:52:41 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E00F3A6ADE for ; Thu, 31 Mar 2011 19:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.565
X-Spam-Level: 
X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-petlvmEfuJ for ; Thu, 31 Mar 2011 19:52:40 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 942A33A6BC7 for ; Thu, 31 Mar 2011 19:52:39 -0700 (PDT)
Received: by wwa36 with SMTP id 36so2507283wwa.13 for ; Thu, 31 Mar 2011 19:54:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=Yj9JF6DG6CqSoulFngi0VdNWBo+Asx+uXr6UEJaG+VM=; b=pqeg83MjSuio3EmZdXpBFyHFbel2QszDd6ORPHFDzdVO5Bdbg/KibUvpJ0wib/zClp 2K5bGAjc9tPigLPDp8V/BJ7vOB7jpdCxIgRuavIC9pk1dH6y8b3C99i3Va+WvpkkLTG3 sIJjbyxIogzit35vomXnpFzuTHLFekUfw/yQg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Azh2PzwkrEa08iv5zSfCcZwFLy2as6VH/3BM1DAJg9mvbS0q/eL3Js8IY+Uvkso+U4 hh/FTg1loM51h4Y8d7T9pPsDyZPjRymYwGc43klGLQF/KAeJNjj3DCeoHtL//u1db1oo ByL/s8DUB7i4EYdNZkIsujG5mlFc1CEyLBTTY=
MIME-Version: 1.0
Received: by 10.216.145.92 with SMTP id o70mr1329488wej.86.1301626458833; Thu, 31 Mar 2011 19:54:18 -0700 (PDT)
Received: by 10.216.153.41 with HTTP; Thu, 31 Mar 2011 19:54:18 -0700 (PDT)
Date: Thu, 31 Mar 2011 22:54:18 -0400
Message-ID: 
From: David Endicott 
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary=0016e6dd8a62b581eb049fd286a8
Subject: [hybi] HTTP Upgrade - A Modest Proposal
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Apr 2011 02:52:41 -0000

--0016e6dd8a62b581eb049fd286a8
Content-Type: text/plain; charset=ISO-8859-1

While I am not interested in disrupting or derailing the progress being made
on finalizing the Websocket specification, the recent discussions about the
initial HTTP Upgrade handshake leads me to offer up the following proposal
that I believe may resolve the situation.

I propose we drop the HTTP Upgrade element from the WebSocket specification
entirely.  I believe that the co-mingling of HTTP Upgrade with WebSocket is
a confusion of protocols and the two should be more firmly separated.

My justification is:

1. HTTP Upgrade request (and it's response) are properly part of a HTTP
exchange, not a WebSocket one.  The use of HTTP Upgrade as a mechanism to
support WebSockets via a HTTP server is a good and valid use of that HTTP
capability, but it is not unique or specific to WebSocket.   Further,
WebSocket protocol servers may not be part of a HTTP serving environment and
having it answer HTTP (however limited) could confuse client agents.

2. When WebSocket is provided as part of a HTTP server stack, having to
instantiate the WebSocket serving process (thread/handler/etc.) just to
resolve the handshake and determine if a WebSocket connection will actually
proceed is awkward, potentially expensive and possibly insecure.    The
responsibility to determine if the HTTP server will support a HTTP Upgrade
to any given protocol for a given URL is properly the responsibility of the
HTTP server, not WebSocket.   The HTTP server must be able, via the Upgrade
request to consider only (a) the URL and (b) the Upgrade protocol and decide
if it will support it.   If it will, then all further negotiation is the
responsibility of the protocol being upgraded to.

3. If a HTTP server decides that it will allow an HTTP Upgrade to WebSocket
on the requested URL, the HTTP server can restrict the WebSocket serving
process to the docroot of that URL, thereby maintaining consistency of the
HTTP server's URL structure and preventing the WebSocket server process from
affecting any other part of the filesystem as well as establishing a
relative filesystem context for the WebSocket serving process.   The
WebSocket server process should not be allowed to determine the validity,
accessibility, remapping, etc. of the requested URL.  That is the HTTP
server's responsibility.

4. When WebSocket is provided as a stand-alone process, using a HTTP Upgrade
as the handshake presents at least two problems.  (a) changing from
line-oriented I/O (in the HTTP handshake) to a byte-oriented I/O (for
WebSocket frames) is awkward and potentially error prone, and (b) any HTTP
client-agent can potentially make a request to a WebSocket server and get
back a HTTP response, this exposes the availability and capabilities of the
WebSocket server to a client-agent that is not actually a WebSocket client.
  Neither of these concerns is really all that severe, but it is something
to be aware of.


Specifically I propose that the HTTP Upgrade based handshake be removed from
the WebSocket specification and replaced with a Control frame handshake or
negotiation.    This would mean that all WebSocket communication is done in
websocket frames.   This simplifies the implementation and keeps each part
in its own protocol context.   It strengthens the error checking between
client-agents and the WebSocket server.  For example, if a HTTP client-agent
incorrectly makes a request of a stand-alone WebSocket server, the client's
HTTP request will fail as a WebSocket frame and the server can drop the
connection.  The WebSocket server can further be assured that any
establishing connection that can provide valid frames is a client-agent that
is likely a conforming implementation.

Personally I would prefer a negotiation control frame to be used as the
initial exchange.  It defines that capability setup is determined at
connection establishment but also allows the possibility of later
re-negotiation should the situation change.    Failing that, a simple
websocket based handshake would be fine.

A note could be included on the use of the HTTP Upgrade by HTTP servers as a
mechanism to bootstrap a WebSocket connection, but this is no different than
it's use to boot-strap any other protocol.   Separating the two would allow
the implementer to decide if and how they wish to deal the ramifications of
using that mechanism.


Again, let me reiterate that I have no interest in derailing this working
group, I have strong motivation to get a real
bidirectional asynchronous protocol into browser agents as soon as possible,
no matter how mangled the implementation.   I will take good over perfect,
and soon over good.


tl;dr: HTTP is HTTP, WebSocket is WebSocket, do not mix.  Leverage.

--0016e6dd8a62b581eb049fd286a8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

While I am not interested in disrupting or derailing the progress being mad=
e on finalizing the Websocket specification, the recent discussions about t=
he initial HTTP Upgrade handshake leads me to offer up the following propos=
al that I believe may resolve the situation. =A0=A0


I propose we drop the HTTP Upgrade element from the WebSocke=
t specification entirely. =A0I believe that the co-mingling of HTTP Upgrade=
 with WebSocket is a confusion of protocols and the two should be more firm=
ly=A0separated.


My justification is:

1. HTTP Upg=
rade request (and it's response) are properly part of a HTTP exchange, =
not a WebSocket one. =A0The use of HTTP Upgrade as a mechanism to support W=
ebSockets via a HTTP server is a good and valid use of that HTTP capability=
, but it is not unique or specific to WebSocket. =A0 Further, WebSocket pro=
tocol servers may not be part of a HTTP serving=A0environment and having it=
 answer HTTP (however limited) could confuse client agents. =A0=A0



2. When WebSocket is provided as part of a HTTP server =
stack, having to instantiate the WebSocket serving process (thread/handler/=
etc.) just to resolve the handshake and determine if a WebSocket connection=
 will actually proceed is awkward, potentially expensive and=A0possibly=A0i=
nsecure. =A0 =A0The responsibility to determine if the HTTP server will sup=
port a HTTP Upgrade to any given protocol for a given URL is properly the r=
esponsibility of the HTTP server, not WebSocket. =A0 The HTTP server must b=
e able, via the Upgrade request to consider only (a) the URL and (b) the Up=
grade protocol and decide if it will support it. =A0 If it will, then all f=
urther=A0negotiation=A0is the responsibility of the protocol being upgraded=
 to.



3. If a HTTP server decides that it will allow an HTTP =
Upgrade to WebSocket on the requested URL, the HTTP server can restrict the=
 WebSocket serving process to the docroot of that URL, thereby maintaining =
consistency of the HTTP server's URL structure and preventing the WebSo=
cket server process from affecting any other part of the filesystem as well=
 as establishing a relative filesystem context for the WebSocket serving pr=
ocess. =A0 The WebSocket server process should not be allowed to determine =
the validity, accessibility, remapping, etc. of the requested URL. =A0That =
is the HTTP server's responsibility.



4. When WebSocket is provided as a stand-alone process,=
 using a HTTP Upgrade as the handshake presents at least two problems. =A0(=
a) changing from line-oriented I/O (in the HTTP handshake) to a byte-orient=
ed I/O (for WebSocket frames) is awkward and potentially error prone, and (=
b) any HTTP client-agent can potentially make a request to a WebSocket serv=
er and get back a HTTP response, this exposes the availability and capabili=
ties of the WebSocket server to a client-agent that is not actually a WebSo=
cket client. =A0 Neither of these concerns is really all that severe, but i=
t is something to be aware of.


=A0

Specifically I propose that the HTTP Upgr=
ade based handshake be removed from the WebSocket specification and replace=
d with a Control frame handshake or negotiation. =A0 =A0This would mean tha=
t all WebSocket communication is done in websocket frames. =A0 This simplif=
ies the implementation and keeps each part in its own protocol context. =A0=
 It strengthens the error checking between client-agents and the WebSocket =
server. =A0For example, if a HTTP client-agent incorrectly makes a request =
of a stand-alone WebSocket server, the client's HTTP request will fail =
as a WebSocket frame and the server can drop the connection. =A0The WebSock=
et server can further be assured that any establishing connection that can =
provide valid frames is a client-agent that is likely a conforming implemen=
tation.



Personally I would prefer a=A0negotiation=A0control fra=
me to be used as the initial exchange. =A0It defines that capability setup =
is determined at connection establishment but also allows the possibility o=
f later re-negotiation=A0should the situation change. =A0 =A0Failing that, =
a simple websocket based handshake would be fine.



A note could be included on the use of the HTTP Upgrade=
 by HTTP servers as a mechanism to bootstrap a WebSocket connection, but th=
is is no different than it's use to boot-strap any other protocol. =A0=
=A0Separating=A0the two would allow the implementer to decide if and how th=
ey wish to deal the ramifications of using that mechanism. =A0=A0




Again, let me reiterate that I have no i=
nterest in derailing this working group, I have strong motivation to get a =
real bidirectional=A0asynchronous=A0protocol into browser agents as soon as=
 possible, no matter how mangled the implementation. =A0 I will take good o=
ver perfect, and soon over good.




tl;dr: HTTP is HTTP, WebSocket is WebSoc=
ket, do not mix. =A0Leverage.



--0016e6dd8a62b581eb049fd286a8--

From Greg@ChampionEnt.net  Thu Mar 31 21:05:42 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEF53A6BD0 for ; Thu, 31 Mar 2011 21:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.139
X-Spam-Level: 
X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=0.460,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmkkEVJEAyXV for ; Thu, 31 Mar 2011 21:05:41 -0700 (PDT)
Received: from smtpout-1.iphouse.net (smtpout-1.iphouse.net [209.240.70.140]) by core3.amsl.com (Postfix) with ESMTP id B47723A6B15 for ; Thu, 31 Mar 2011 21:05:41 -0700 (PDT)
Received: from smtpout-1.iphouse.net (localhost [127.0.0.1]) by outbound-clamsmtpd.iphouse.net (Postfix) with ESMTP id 2797F1CDB2 for ; Thu, 31 Mar 2011 23:07:21 -0500 (CDT)
Received: from GJL8710w (longtin.dsl.visi.com [209.98.144.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpout-1.iphouse.net (Postfix) with ESMTPSA id D03E61CCEE for ; Thu, 31 Mar 2011 23:07:20 -0500 (CDT)
From: "Greg Longtin" 
To: "hybi" 
References: 
In-Reply-To: 
Date: Thu, 31 Mar 2011 23:07:19 -0500
Message-ID: <000601cbf022$4c420320$e4c60960$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcvwGBwC/1YRlbMTQ0+D7lq0Rs4YSAABCvxg
Content-Language: en-us
X-Virus-Scanned: ClamAV using ClamSMTP
Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Apr 2011 04:05:42 -0000

David,

A few thoughts on your post (clipped) --

> 1. Further, WebSocket protocol servers may not be part of a HTTP serving
environment and having it answer HTTP (however limited) could confuse client
agents.

I'm not sure I understand the 'confuse client agents' concept.  If a client
agent includes the header 'Upgrade: websocket' in an HTTP request, it should
be expecting the response as defined in the spec.


> 2. When WebSocket is provided as part of a HTTP server stack, having to
instantiate the WebSocket serving process (thread/handler/etc.) just to
resolve the handshake

I'm not sure why 'when A' implies 'B.'  Somewhere, the stack needs know what
will be considered valid 'Request-URI' and possibly 'Sec-WebSocket-Protocol'
information.  That is a concern of whomever administers the stack.


> 4 (a) changing from line-oriented I/O (in the HTTP handshake) to a
byte-oriented I/O (for WebSocket frames) is awkward and potentially error
prone

Considering WS servers will be designed for byte-oriented I/O, the
line-oriented I/O coding requirements are minimal, and not necessarily error
prone.


> 4 (b) any HTTP client-agent can potentially make a request to a WebSocket
server and get back a HTTP response, this exposes the availability and
capabilities of the WebSocket server

Without the correct Request-URI and possibly 'Sec-WebSocket-Protocol'
header, what can the client find out?  If the HTTP client request is
invalid, the spec states (somewhat vaguely) in Section 7.2.2. the following
'Certain algorithms require or recommend that the server _abort the
WebSocket connection_ during the opening handshake.'  Hence, 'get back a
HTTP response' may not occur with the client agent's request.


I think everyone is a little sensitive and spent from all the reading. 

Thanks,

Greg Longtin


From Greg@ChampionEnt.net  Thu Mar 31 21:07:53 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B7E3A6BD0 for ; Thu, 31 Mar 2011 21:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.292
X-Spam-Level: 
X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[AWL=0.307,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOfn-x6He+tn for ; Thu, 31 Mar 2011 21:07:53 -0700 (PDT)
Received: from smtpout-1.iphouse.net (smtpout-1.iphouse.net [209.240.70.140]) by core3.amsl.com (Postfix) with ESMTP id 26CA73A6B15 for ; Thu, 31 Mar 2011 21:07:52 -0700 (PDT)
Received: from smtpout-1.iphouse.net (localhost [127.0.0.1]) by outbound-clamsmtpd.iphouse.net (Postfix) with ESMTP id 10F091CC76 for ; Thu, 31 Mar 2011 23:09:33 -0500 (CDT)
Received: from GJL8710w (longtin.dsl.visi.com [209.98.144.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpout-1.iphouse.net (Postfix) with ESMTPSA id AF0EF1CC30 for ; Thu, 31 Mar 2011 23:09:32 -0500 (CDT)
From: "Greg Longtin" 
To: "hybi" 
Date: Thu, 31 Mar 2011 23:09:31 -0500
Message-ID: <000701cbf022$9adb51d0$d091f570$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcvwIppT0m9QtzGITweH4vg1OiKDuA==
Content-Language: en-us
X-Virus-Scanned: ClamAV using ClamSMTP
Subject: [hybi] Two Questions
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Apr 2011 04:07:53 -0000

To all,

I had to ask...

I would like to know, from an HTTP perspective, if a generic and valid
*HTTP* upgrade request cannot be replied to, per the HTTP spec.  This (a
none response) seems to be a correct response per the WS 06 spec to an
invalid *WebSocket* upgrade/handshake request from a client.
 
Secondly, I am still unclear on whether WS *can* or *must* use ports 80 /
443.  Section 1.7 uses the term 'by default'.  I think that implies *can* or
*should* but not *must*...


Greg Longtin


From w@1wt.eu  Thu Mar 31 22:20:22 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF723A67F1 for ; Thu, 31 Mar 2011 22:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.678
X-Spam-Level: 
X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4t7y6iopO1C for ; Thu, 31 Mar 2011 22:20:18 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 705C13A67E1 for ; Thu, 31 Mar 2011 22:20:16 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p315LoOq000680; Fri, 1 Apr 2011 07:21:50 +0200
Date: Fri, 1 Apr 2011 07:21:50 +0200
From: Willy Tarreau 
To: Greg Longtin 
Message-ID: <20110401052150.GA658@1wt.eu>
References:  <000601cbf022$4c420320$e4c60960$@net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000601cbf022$4c420320$e4c60960$@net>
User-Agent: Mutt/1.4.2.3i
Cc: hybi 
Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Apr 2011 05:20:22 -0000

On Thu, Mar 31, 2011 at 11:07:19PM -0500, Greg Longtin wrote:
> > 4 (a) changing from line-oriented I/O (in the HTTP handshake) to a
> > byte-oriented I/O (for WebSocket frames) is awkward and potentially error
> > prone
> 
> Considering WS servers will be designed for byte-oriented I/O, the
> line-oriented I/O coding requirements are minimal, and not necessarily error
> prone.

I would add that any HTTP server already deals with that. They accept
POST requests which are byte-oriented, they can send any file (eg: HTML,
GIF, etc...) which are byte-oriented too and browsers can correctly
retrieve these files. So in fact it's something which is already
implemented and works very well in every client and server.

> > 4 (b) any HTTP client-agent can potentially make a request to a WebSocket
> > server and get back a HTTP response, this exposes the availability and
> > capabilities of the WebSocket server
> 
> Without the correct Request-URI and possibly 'Sec-WebSocket-Protocol'
> header, what can the client find out?  If the HTTP client request is
> invalid, the spec states (somewhat vaguely) in Section 7.2.2. the following
> 'Certain algorithms require or recommend that the server _abort the
> WebSocket connection_ during the opening handshake.'  Hence, 'get back a
> HTTP response' may not occur with the client agent's request.

There were discussions in the past about exposing some capabilities as
control frames, but that did not bring any major advantage, and that
required an additional round-trip before communication could start,
which is really not acceptable in some environments (eg: smartphones).

Willy


From w@1wt.eu  Thu Mar 31 22:35:11 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC583A69B9 for ; Thu, 31 Mar 2011 22:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.667
X-Spam-Level: 
X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, NORMAL_HTTP_TO_IP=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLA5SW7x7kxN for ; Thu, 31 Mar 2011 22:35:07 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id A9DAE3A67F1 for ; Thu, 31 Mar 2011 22:35:05 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p315agXs000718; Fri, 1 Apr 2011 07:36:42 +0200
Date: Fri, 1 Apr 2011 07:36:42 +0200
From: Willy Tarreau 
To: Adam Barth 
Message-ID: <20110401053642.GC658@1wt.eu>
References:  
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org, info@meetecho.com
Subject: Re: [hybi] HYBI recording available
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Apr 2011 05:35:11 -0000

Hi Adam,

On Thu, Mar 31, 2011 at 05:46:36PM -0700, Adam Barth wrote:
> That's all very nice, but I'm not going to audit your Java source code
> in order to watch this content.  However, I would very much like to
> watch the video in my browser.  I doubt I'm the only one.

Indeed, and you can use the link below which contains the video, it works
for me with mplayer :

   http://143.225.229.137/recordings/hybi/video.mov

Thanks for the link, meetecho guys, it's *much* easier for me to use that
way, I don't have to install/upgrade whatever component on my machines.

Regards,
Willy


From ietf@adambarth.com  Thu Mar 31 23:14:37 2011
Return-Path: 
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454403A6AE9 for ; Thu, 31 Mar 2011 23:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.803
X-Spam-Level: 
X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=0.173,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cshzNjNxbuEH for ; Thu, 31 Mar 2011 23:14:36 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 4BFD83A69D2 for ; Thu, 31 Mar 2011 23:14:36 -0700 (PDT)
Received: by iye19 with SMTP id 19so3647858iye.31 for ; Thu, 31 Mar 2011 23:16:16 -0700 (PDT)
Received: by 10.43.62.10 with SMTP id wy10mr1349911icb.37.1301638576240; Thu, 31 Mar 2011 23:16:16 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id wo11sm1096879icb.8.2011.03.31.23.16.13 (version=SSLv3 cipher=OTHER); Thu, 31 Mar 2011 23:16:13 -0700 (PDT)
Received: by iye19 with SMTP id 19so3647816iye.31 for ; Thu, 31 Mar 2011 23:16:13 -0700 (PDT)
Received: by 10.42.147.196 with SMTP id o4mr4724239icv.183.1301638573115; Thu, 31 Mar 2011 23:16:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.133.200 with HTTP; Thu, 31 Mar 2011 23:15:43 -0700 (PDT)
In-Reply-To: <20110401053642.GC658@1wt.eu>
References:   <20110401053642.GC658@1wt.eu>
From: Adam Barth 
Date: Thu, 31 Mar 2011 23:15:43 -0700
Message-ID: 
To: Willy Tarreau 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, info@meetecho.com
Subject: Re: [hybi] HYBI recording available
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Apr 2011 06:14:37 -0000

On Thu, Mar 31, 2011 at 10:36 PM, Willy Tarreau  wrote:
> On Thu, Mar 31, 2011 at 05:46:36PM -0700, Adam Barth wrote:
>> That's all very nice, but I'm not going to audit your Java source code
>> in order to watch this content. =A0However, I would very much like to
>> watch the video in my browser. =A0I doubt I'm the only one.
>
> Indeed, and you can use the link below which contains the video, it works
> for me with mplayer :
>
> =A0 http://143.225.229.137/recordings/hybi/video.mov
>
> Thanks for the link, meetecho guys, it's *much* easier for me to use that
> way, I don't have to install/upgrade whatever component on my machines.

Yay!  /me goes and gets some popcorn.

Adam