From tyoshino@google.com Mon Jul 2 22:41:07 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7D321F876A for ; Mon, 2 Jul 2012 22:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5P5QB2Aewp0 for ; Mon, 2 Jul 2012 22:41:07 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED8F921F8768 for ; Mon, 2 Jul 2012 22:41:06 -0700 (PDT) Received: by yenq13 with SMTP id q13so5392679yen.31 for ; Mon, 02 Jul 2012 22:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record; bh=/Tq+wlr1HiSBxKXro5rI2ZxC9EtSSmwGwrYegNV4HjM=; b=Kl8KONOvYFXQ+Aw2qZ55Q7VMD5gfVx9fKMrxB4jESHJvCD53c6KCOLxN+fcm/+qnJN BHxWXNabEdJCIEHrekba2Wucw8+ENjRKh4eQ5xGX5GsgdrbwxhasAuUHehEZMlrGU/uH luRCVT0tV6mjBsSlRxJj+EhWDMdoSIEryFY9yT70EyWfVT4H/wkOtg8yIwwoNvWiQw40 OCfK6Np4cCgpSoV9wwDXBDgbyN85rRzio+Dpas9EFGcjEoeBnodO92Bn088QMmPNogga CzkWUtD61HoK8Wsxpjsx7J1ZlRzO8PxiIO3Ypfa65enHrPA8wUiRyAsI4GRXpaqO6Wd4 Qaqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record:x-gm-message-state; bh=/Tq+wlr1HiSBxKXro5rI2ZxC9EtSSmwGwrYegNV4HjM=; b=RcD0XYd9r/uHW57zO76MWsxKj5j7NDu7+oBJ6Of88lQjybcfj2VThZFXXQozs2ULwf RRZvEaWq9bRlhAK004/qG2Jgh8SDD8zP3wlr9IQ5M3J9V9nWR7SPrf/zY3NRfVDxqqgu JbxI+dPA0hnV3JAmCQ0AdLBAHlpvQeuMrYmjS24lqafTtaOJXj0CVNx5adqsajVaAGyW 4xuspDeLJi514wMmBe/joxJT74YOBq4xoKv3xEiVMIoc5343h+b0kWyNy6MwxYwyW843 KBZr5P+S7Ot9PTCcLZUvM2RTuGiEPzKMK9kYlFaO44Ume5jzNtxA3TMtfOX1kiEHpJQO JULA== Received: by 10.50.106.136 with SMTP id gu8mr7332893igb.23.1341294073136; Mon, 02 Jul 2012 22:41:13 -0700 (PDT) Received: by 10.50.106.136 with SMTP id gu8mr7332889igb.23.1341294072970; Mon, 02 Jul 2012 22:41:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Mon, 2 Jul 2012 22:40:52 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Tue, 3 Jul 2012 14:40:52 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=e89a8f23579dc23e4404c3e65c13 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkWgqHpNeS4f2A9jzDtLU3u08T02Ow+QgDeZeuHi7TfEUx23wtKKAyB66/39Oz0P8GOXK9N73yLulteKDAfB0Ko64TSk+VYFnG6JMbqYYlvKy9z0Dg/3GKh10XLgLWPGAHgvgqeb7nXTiaRV+lmTz2EnzYtSMC2NcpsBxX2xFUNXseyi7I= Subject: Re: [hybi] Call for opinions on multiplexing (separate layer for multiplexing, again) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 05:41:08 -0000 --e89a8f23579dc23e4404c3e65c13 Content-Type: text/plain; charset=ISO-8859-1 Hi, I got some support on the thread discussing this issue, so I'm going to make some change on both compression extension and multiplexing extension. This approach sweeps away most of concerns (intermediary, future extension, mux-compress integration, etc.) by 1 octet/frame additional overhead for mux and sacrificing per-frame signaling (any extension flipping bit or placing different extension data for each frame. any extension expecting frame boundary to be preserved between endpoints). The role of fragmentation will be limited to transporting a big message being split into smaller chunks and interleaved with other channels' data, control frames. Nothing else will be carried by fragmentation. === Compression === algorithm - per-frame -> per-message -- RSV1 bit is set on the first fragment of compressed message. Not for each frame -- strip 4 octet at the end of the message. Not for each frame - compress only Application data -> compress payload pros - doesn't lock fragment. non-compression-aware intermediaries can safely re-fragment - no need to send feedback from multiplexing processing module to compression module to adjust fragment size to fit flow-control quota cons - original frame boundary is not guaranteed to be preserved - compressed data for one byte in the original frame may be split into two frames - since non-compression-aware intermediaries can re-fragment, endpoints cannot use per-frame signaling safely === Multiplexing === algorithm - adjusts fragment according to quota - then, encapsulates each frame into a binary message -- frame (after adjustment) and encapsulating message correspond 1-to-1 -- strip (extended) payload length, mask bit and masking-key from the original frame - puts the channel ID data at the head of the encapsulating message pros - output frame sequence is not interleaved -- per-message compression can be used before/after multiplexing - non-multiplexing-capable intermediaries can safely -- re-fragment -- insert Ping/Pong/Close cons - original frame boundary is not guaranteed to be preserved - cannot be applied after any extension that uses per-frame signal - 1 byte additional overhead compared to draft-ietf-hybi-websocket-multiplexing-02 --e89a8f23579dc23e4404c3e65c13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I got some support on the thread discussing this i= ssue, so I'm going to make some change on both compression extension an= d multiplexing extension.

This approa= ch sweeps away most of concerns (intermediary, future extension, mux-compre= ss integration, etc.) by 1 octet/frame additional overhead for mux and sacr= ificing per-frame signaling (any extension flipping bit or placing differen= t extension data for each frame. any extension expecting frame boundary to = be preserved between endpoints).

The role of= fragmentation will be limited to transporting a big message being split in= to smaller chunks and interleaved with other channels' data, control fr= ames. Nothing else will be carried by fragmentation.

=3D=3D=3D C= ompression =3D=3D=3D

algorithm
- per-frame ->= ; per-message
-- RSV1 bit is set on the first fragment of compressed message. Not for eac= h frame
-- strip 4 octet at the end of the = message. Not for each frame
- compress only= Application data -> compress payload

pros
<= div class=3D"gmail_extra">- doesn't lock fragment. non-compression-awar= e intermediaries can safely re-fragment
- n= o need to send feedback from multiplexing processing module to compression = module to adjust fragment size to fit flow-control quota

cons
<= div class=3D"gmail_extra">- original frame boundary is=A0not guaranteed to = be preserved
- compressed data for one byte= in the original frame may be split into two frames
- since non-compression-aware intermediaries can= re-fragment, endpoints cannot use per-frame signaling safely

=3D=3D=3D Multiplex= ing =3D=3D=3D

algor= ithm
- adjusts fragment according to quota<= /div>
- then, encapsulates each frame into a bina= ry message
-- frame (after adjustment) and encapsulating me= ssage correspond 1-to-1
-- strip (extended)= payload length, mask bit and masking-key from the original frame
- puts the channel ID data at the head of the encapsulating message

pros
- output frame sequence is not interleaved -- per-message compression can be used before/after multiplexing
- non-multiplexing-capable intermediaries can safely<= /div>
-- re-fragment
-- insert Ping/Pong/Close

cons
- original frame b= oundary is not guaranteed to be preserved
-= cannot be applied after any extension that uses per-frame signal
- 1 byte additional overhead compared to draft-i= etf-hybi-websocket-multiplexing-02

--e89a8f23579dc23e4404c3e65c13-- From sustrik@250bpm.com Tue Jul 3 01:08:22 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196B821F86A7 for ; Tue, 3 Jul 2012 01:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwWBpsV+ovl8 for ; Tue, 3 Jul 2012 01:08:21 -0700 (PDT) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B25821F8609 for ; Tue, 3 Jul 2012 01:08:21 -0700 (PDT) Received: from [192.168.1.134] (188-167-109-79.dynamic.chello.sk [188.167.109.79]) by mail.moloch.sk (Postfix) with ESMTPSA id E86F618011A5; Tue, 3 Jul 2012 10:08:26 +0200 (CEST) Message-ID: <4FF2A87A.8060803@250bpm.com> Date: Tue, 03 Jul 2012 10:08:26 +0200 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: Takeshi Yoshino 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] Call for opinions on multiplexing (separate layer for multiplexing, again) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 08:08:22 -0000 On 03/07/12 07:40, Takeshi Yoshino wrote: > algorithm > - adjusts fragment according to quota > - then, encapsulates each frame into a binary message > -- frame (after adjustment) and encapsulating message correspond 1-to-1 > -- strip (extended) payload length, mask bit and masking-key from the > original frame > - puts the channel ID data at the head of the encapsulating message +1 Martin From arman@noemax.com Tue Jul 3 03:49:50 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B0F21F87E9 for ; Tue, 3 Jul 2012 03:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvsRDQAZ10iF for ; Tue, 3 Jul 2012 03:49:49 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id A0BDA21F86C3 for ; Tue, 3 Jul 2012 03:49:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1341312593; x=1341917393; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=SIqsvkkBchm7Q/c5XovwWilTfNU=; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:In-Reply-To:References; b=exaBfiDbSwfxY84XK+LmMwnt/9H4hQHJwiyaKvfzOqfIt0Uz35gUOrgO8sbzEkwjrVuRoDhKPTDQ1xwMOR2hjUEZcvlTi7wH3zqQpc56vRQs+mboFhFa0LUAZIaeWVXE8B/yJYa1BW4lV4dmfZvGDFx4FYwjGJorxHywU4klDuM= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id NRA10151; Tue, 03 Jul 2012 13:49:51 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" , References: In-Reply-To: Date: Tue, 3 Jul 2012 13:49:40 +0300 Message-ID: <000801cd5909$91910330$b4b30990$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01CD5922.B6DFC1D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH16F0Nw0y5wKEmQGWHWhxDoKcZrwFYZHDmlrt+foA= Content-Language: en-us Subject: Re: [hybi] Call for opinions on multiplexing (separate layer for multiplexing, again) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 10:49:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0009_01CD5922.B6DFC1D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1, this is in tune with the changes I wished to be made to the spec. With best regards, Arman From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino Sent: Tuesday, July 03, 2012 8:41 AM To: hybi@ietf.org Subject: Re: [hybi] Call for opinions on multiplexing (separate layer for multiplexing, again) Hi, I got some support on the thread discussing this issue, so I'm going to make some change on both compression extension and multiplexing extension. This approach sweeps away most of concerns (intermediary, future extension, mux-compress integration, etc.) by 1 octet/frame additional overhead for mux and sacrificing per-frame signaling (any extension flipping bit or placing different extension data for each frame. any extension expecting frame boundary to be preserved between endpoints). The role of fragmentation will be limited to transporting a big message being split into smaller chunks and interleaved with other channels' data, control frames. Nothing else will be carried by fragmentation. === Compression === algorithm - per-frame -> per-message -- RSV1 bit is set on the first fragment of compressed message. Not for each frame -- strip 4 octet at the end of the message. Not for each frame - compress only Application data -> compress payload pros - doesn't lock fragment. non-compression-aware intermediaries can safely re-fragment - no need to send feedback from multiplexing processing module to compression module to adjust fragment size to fit flow-control quota cons - original frame boundary is not guaranteed to be preserved - compressed data for one byte in the original frame may be split into two frames - since non-compression-aware intermediaries can re-fragment, endpoints cannot use per-frame signaling safely === Multiplexing === algorithm - adjusts fragment according to quota - then, encapsulates each frame into a binary message -- frame (after adjustment) and encapsulating message correspond 1-to-1 -- strip (extended) payload length, mask bit and masking-key from the original frame - puts the channel ID data at the head of the encapsulating message pros - output frame sequence is not interleaved -- per-message compression can be used before/after multiplexing - non-multiplexing-capable intermediaries can safely -- re-fragment -- insert Ping/Pong/Close cons - original frame boundary is not guaranteed to be preserved - cannot be applied after any extension that uses per-frame signal - 1 byte additional overhead compared to draft-ietf-hybi-websocket-multiplexing-02 ------=_NextPart_000_0009_01CD5922.B6DFC1D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1, this is in tune with the changes I wished to be made to the = spec.

 

With best regards,

Arman

 

From:= = hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = Takeshi Yoshino
Sent: Tuesday, July 03, 2012 8:41 = AM
To: hybi@ietf.org
Subject: Re: [hybi] Call for = opinions on multiplexing (separate layer for multiplexing, = again)

 

Hi,

 

I = got some support on the thread discussing this issue, so I'm going to = make some change on both compression extension and multiplexing = extension.

 

This approach sweeps away most of concerns = (intermediary, future extension, mux-compress integration, etc.) by 1 = octet/frame additional overhead for mux and sacrificing per-frame = signaling (any extension flipping bit or placing different extension = data for each frame. any extension expecting frame boundary to be = preserved between endpoints).

 

The role of fragmentation will be limited to = transporting a big message being split into smaller chunks and = interleaved with other channels' data, control frames. Nothing else will = be carried by fragmentation.

 

=3D=3D=3D Compression = =3D=3D=3D

 

algorithm

- per-frame -> = per-message

-- RSV1 bit is = set on the first fragment of compressed message. Not for each = frame

-- strip 4 octet at = the end of the message. Not for each frame

- compress only Application data -> compress = payload

 

pros

- = doesn't lock fragment. non-compression-aware intermediaries can safely = re-fragment

- no need to = send feedback from multiplexing processing module to compression module = to adjust fragment size to fit flow-control = quota

 

cons

- = original frame boundary is not guaranteed to be = preserved

- compressed = data for one byte in the original frame may be split into two = frames

- since = non-compression-aware intermediaries can re-fragment, endpoints cannot = use per-frame signaling safely

 

=3D=3D=3D Multiplexing = =3D=3D=3D

 

algorithm

- adjusts fragment according to = quota

- then, encapsulates = each frame into a binary message

-- frame (after adjustment) and encapsulating message = correspond 1-to-1

-- strip = (extended) payload length, mask bit and masking-key from the original = frame

- puts the channel = ID data at the head of the encapsulating = message

 

pros

- = output frame sequence is not interleaved

-- per-message compression can be used before/after = multiplexing

- = non-multiplexing-capable intermediaries can = safely

-- = re-fragment

-- insert = Ping/Pong/Close

 

cons

- = original frame boundary is not guaranteed to be = preserved

- cannot be = applied after any extension that uses per-frame = signal

- 1 byte additional = overhead compared to = draft-ietf-hybi-websocket-multiplexing-02

 

------=_NextPart_000_0009_01CD5922.B6DFC1D0-- From tyoshino@google.com Tue Jul 3 23:12:54 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AD321F85A4 for ; Tue, 3 Jul 2012 23:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSdaFowpVXtf for ; Tue, 3 Jul 2012 23:12:54 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB29121F85A1 for ; Tue, 3 Jul 2012 23:12:53 -0700 (PDT) Received: by yenq13 with SMTP id q13so6710171yen.31 for ; Tue, 03 Jul 2012 23:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record; bh=Q3y84ZRfJxtJ7bA+5fua/tbnflAuO1OsJfqimwU4VGE=; b=Ir3a3azNGkiwvtaYDXdIY714K4VKlGpa5912w8S3qQZE33I5yU+d0AaZYB1Qle54lO /9Ji/7R9rrF+aqXHXmatvbjRFeiHdVn7ZBmbQkMPz2NUrQx8UwQuvwkneudw5Wnju/NI emIS7YiEmhoZhIP1F6zvtCg/9lbl67+SHWzISuURWEep2qx5CRQdWIE6wL1+FBMEhY6J /PGw2Nk294U27AZ1GPybTyIUhqS2PLqg7pISEgwVnDujo3MqeA1oGsnEbDidW0mwHQWs U1P0QrT2SOLc9XC8EyZQL/fcv+qKPrgdUhpFVaj+8z5DCTWCIwSUWSXlsAbkHVCEy2sQ hJvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record:x-gm-message-state; bh=Q3y84ZRfJxtJ7bA+5fua/tbnflAuO1OsJfqimwU4VGE=; b=kpTli+t/x1gMolqCURPygjnWZZPKXcqOxd3IsGyDNRkPgVtn0BVeLr1NQFG5Mo62DL kII+/VuX/ZKpfoyFGaWEM1mFUSo2H4O6tPD6mXl2CuVipJjgyPTWup4iYzNrHnobiGWo bmZwmnWvJamz+3U5H1FjmAm5mntIeSI0eLxY2pehWRwK0+tBKeTLCHEJo1o6nd2Skj4a 7Vq3JNcpx0c6To1ViVIAYTupSiZGtKRx6cMqXC9vz4kPI24hOycPeadn/DjCmjbfHv7Z WewtpFdwfU7U3plGI7cBiqInymLfCh8f14kFqxu8lP+YK3s2fq1GcMdKS5Jpp5aGGJ+c OxZA== Received: by 10.50.183.228 with SMTP id ep4mr10631277igc.74.1341382383007; Tue, 03 Jul 2012 23:13:03 -0700 (PDT) Received: by 10.50.183.228 with SMTP id ep4mr10631266igc.74.1341382382854; Tue, 03 Jul 2012 23:13:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Tue, 3 Jul 2012 23:12:42 -0700 (PDT) In-Reply-To: <20120704060501.10520.77949.idtracker@ietfa.amsl.com> References: <20120704060501.10520.77949.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Wed, 4 Jul 2012 15:12:42 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=14dae934064f7022eb04c3faecd1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkSwbYPW7PbP4usD14yLEnb3cEJs6+GILiCIm3i/WIbLN1/SRf7hK3ezP61ERjUb2IOMV6XQj1UE4IMpddc9gmf9TTlxODTlLFk26a10c1eX0AXUL0c+WvUv954g2H8BIBD7tjycTdzFoOkrNngl/nWZjhX7UAJxxLUN5ILtPPsgY1n3Uk= Subject: Re: [hybi] New Version Notification for draft-tyoshino-hybi-permessage-compression-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 06:12:55 -0000 --14dae934064f7022eb04c3faecd1 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Here's the per-message compression spec draft. Because of big change (per-frame to per-message. The name of the draft need to be changed...), I've uploaded the new version as a separate I-D for now to get it reviewed sooner. Text change from perframe -04 is not big. Changed per-frame to per-message and added some note about compatibility with other extensions. http://tools.ietf.org/rfcdiff?url1=draft-ietf-hybi-websocket-perframe-compression-04.txt&url2=draft-tyoshino-hybi-permessage-compression-00 On Wed, Jul 4, 2012 at 3:05 PM, wrote: > > A new version of I-D, draft-tyoshino-hybi-permessage-compression-00.txt > has been successfully submitted by Takeshi Yoshino and posted to the > IETF repository. > > Filename: draft-tyoshino-hybi-permessage-compression > Revision: 00 > Title: WebSocket Per-message Compression > Creation date: 2012-07-04 > WG ID: Individual Submission > Number of pages: 17 > URL: > http://www.ietf.org/internet-drafts/draft-tyoshino-hybi-permessage-compression-00.txt > Status: > http://datatracker.ietf.org/doc/draft-tyoshino-hybi-permessage-compression > Htmlized: > http://tools.ietf.org/html/draft-tyoshino-hybi-permessage-compression-00 > > > Abstract: > This specification defines a WebSocket extension that adds > compression functionality to the WebSocket Protocol. It compresses > the payload of non-control WebSocket messages using specified > compression algorithm. One reserved bit RSV1 in the WebSocket frame > header is allocated to control application of compression for each > message. This specification provides one compression method > available for the extension using DEFLATE. > > Please send feedback to the hybi@ietf.org mailing list. > > > > > The IETF Secretariat > --14dae934064f7022eb04c3faecd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Here's the per-message compression spec dr= aft.

B= ecause of big change (per-frame to per-message. The name of the draft need = to be changed...), I've uploaded the new version as a separate I-D for = now to get it reviewed sooner.

Text change= from perframe -04 is not big. Changed per-frame to per-message and added s= ome note about compatibility with other extensions.
http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-hybi-websocket-pe= rframe-compression-04.txt&url2=3Ddraft-tyoshino-hybi-permessage-compres= sion-00=A0

On Wed, Jul= 4, 2012 at 3:05 PM, <internet-drafts@ietf.org> wrot= e:

A new version of I-D, draft-tyoshino-hybi-permessage-compression-00.txt
has been successfully submitted by Takeshi Yoshino and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-tyoshino-hybi-permessage-compression
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 WebSocket Per-message Compression
Creation date: =A0 2012-07-04
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 17
URL: =A0 =A0 =A0 =A0 =A0 =A0 http:= //www.ietf.org/internet-drafts/draft-tyoshino-hybi-permessage-compression-0= 0.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker= .ietf.org/doc/draft-tyoshino-hybi-permessage-compression
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/= html/draft-tyoshino-hybi-permessage-compression-00


Abstract:
=A0 =A0This specification defines a WebSocket extension that adds
=A0 =A0compression functionality to the WebSocket Protocol. =A0It compresse= s
=A0 =A0the payload of non-control WebSocket messages using specified
=A0 =A0compression algorithm. =A0One reserved bit RSV1 in the WebSocket fra= me
=A0 =A0header is allocated to control application of compression for each =A0 =A0message. =A0This specification provides one compression method
=A0 =A0available for the extension using DEFLATE.

=A0 =A0Please send feedback to the hybi@ie= tf.org mailing list.




The IETF Secretariat

--14dae934064f7022eb04c3faecd1-- From internet-drafts@ietf.org Wed Jul 4 00:59:51 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8144121F87E0; Wed, 4 Jul 2012 00:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNIDFXdSsj8I; Wed, 4 Jul 2012 00:59:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1372F21F87E7; Wed, 4 Jul 2012 00:59:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30 Message-ID: <20120704075951.24580.48630.idtracker@ietfa.amsl.com> Date: Wed, 04 Jul 2012 00:59:51 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-03.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 07:59:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the BiDirectional or Server-Initiated HTTP Wo= rking Group of the IETF. Title : A Multiplexing Extension for WebSockets Author(s) : John A. Tamplin Takeshi Yoshino Filename : draft-ietf-hybi-websocket-multiplexing-03.txt Pages : 35 Date : 2012-07-04 Abstract: The WebSocket Protocol [RFC6455] requires a new transport connection for every WebSocket connection. This presents a scalability problem when many clients connect to the same server, and is made worse by having multiple clients running in different tabs of the same user agent. This extension provides a way for separate logical WebSocket connections to share an underlying transport connection. Please send feedback to the hybi@ietf.org mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hybi-websocket-multiplexing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-hybi-websocket-multiplexing= -03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tyoshino@google.com Wed Jul 4 01:13:23 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8A121F8704 for ; Wed, 4 Jul 2012 01:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGxsT89svFop for ; Wed, 4 Jul 2012 01:13:23 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E51FD21F853F for ; Wed, 4 Jul 2012 01:13:22 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6824508ghb.31 for ; Wed, 04 Jul 2012 01:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record; bh=8ebJTaA9STF5FfKNZBey/om91YzWoGaXCZntTpnjIWo=; b=EDTlWD0sOvbbMSj+tj8nwLX4wuIJbTMsS0a8u9huG9A0qqEOcJxXjKHkA4arJ/U2SM QHAE5z8Au54Kp3N8QpG0qS9uuMdRQMSm/2HZYOAVkctfAy/sEKxJDeucn+ASZzRCb8zx cZF29iNhIyHr0XXj7+kgFDoZCcbnpfP6rjHxIOgsMB2CoB24tEl7soppovigazi2fsLx bC2Lr232+3SIok5XAhlR+pAjKMSJx/2sDQmbfQkVBtAnfd1fL+MG+rr4C/SqoT/9XWsk CycW+6/XZLXKmza08ZWGC1KBXeFmNe8U8WV2FC3T0bHB7grCBWJhaTPObxS7KwdBr08f ynJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record:x-gm-message-state; bh=8ebJTaA9STF5FfKNZBey/om91YzWoGaXCZntTpnjIWo=; b=JtZ6BaY5VkabZOPRxdBscS36O4ugGUai2Krkkku+B6521d3gKsq+nq7vrVscHIwtKM uyCPddZTBzYC0AgV97GHealRXWElxQqvtm/ZVxFeAVNX4p4qZJ15/znJmODNvF8vSGWq Kbnx0aZhOrs7T/zANzfYBYuRDMfoNw2/iTpCETEToNrqguyADe6niaTZLZBqZ8KmsbHx uPUrvI+LGqt4AGoGzWAMq64Jkzx8S88Mmj8BwaDVtHpw9MiWvx8ZcBPUBvS2EiIY4dg3 uurS5V8J3E2AesogQEJuWJARwexHA3A4qDt+0hUC8DUsPx+nf2ALb/dMci5C+3lncmIa sgSw== Received: by 10.50.106.136 with SMTP id gu8mr10828329igb.23.1341389612615; Wed, 04 Jul 2012 01:13:32 -0700 (PDT) Received: by 10.50.106.136 with SMTP id gu8mr10828324igb.23.1341389612516; Wed, 04 Jul 2012 01:13:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Wed, 4 Jul 2012 01:13:12 -0700 (PDT) In-Reply-To: <20120704075951.24580.48630.idtracker@ietfa.amsl.com> References: <20120704075951.24580.48630.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Wed, 4 Jul 2012 17:13:12 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=e89a8f23579d5c06bf04c3fc9be9 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkN3EVUiRI1i4XrQU6ysdR2F0fovGNl1NAhAzNrkkIHYwa4B7fBXjNtxkxaAEfTk/KXKXMiJsR+jhySsTAxBEmkLCsk8f3Ud/Mv+yRjZPBePDb9D8g7y31Sj2az9TqeBZfOwsamcoAkKh56CzY9vkOMx5dUKiJZfKsk3GCeRmFNsq7edMY= Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-03.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 08:13:24 -0000 --e89a8f23579d5c06bf04c3fc9be9 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I just published the new version of multiplexing extension. Changes - [main change] channel ID tagging by Extension data field -> encapsulate each frame into a binary "message" together with channel ID - text for "multiplexed connection" term definition - don't inherit extension tokens after mux (including itself) from the handshake for the physical connection - moved objective channel ID field into Opc specific data area as we've added NewChannelSlot command that is channel independent --e89a8f23579d5c06bf04c3fc9be9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I just published the new version of multiplexi= ng extension.

Changes
- [main change] channel ID tagging = by Extension data field -> encapsulate each frame into a binary "me= ssage" together with channel ID
- text= for "multiplexed connection" term definition
- don't inherit extension tokens after mux (= including itself) from the handshake for the physical connection
- moved objective channel ID field into Opc specific = data area as we've added NewChannelSlot command that is channel indepen= dent

--e89a8f23579d5c06bf04c3fc9be9-- From tyoshino@google.com Wed Jul 4 01:38:10 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A366021F8702 for ; Wed, 4 Jul 2012 01:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMmoBxj89RSX for ; Wed, 4 Jul 2012 01:38:09 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B75221F8700 for ; Wed, 4 Jul 2012 01:38:09 -0700 (PDT) Received: by yhq56 with SMTP id 56so8397780yhq.31 for ; Wed, 04 Jul 2012 01:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record; bh=hTQnYIh0oYfkAKbE/YfBwKfi6ERdEfGXPntJXaKuVgk=; b=ICRnL8MjlPaVD5KZndglGosIF3QVHEV/4Qah0cwuYNQMPwmX48rZPKhCp475ZxN3KG SFwMwUc+nDDtdo5jTAdNoQWE3/csfyqSiz8mGZ7uEOdo+6DhWIPYV3EB9ptXLSkaIr+S fG9TTBeGWBCRLdnbUOSovxd9Uf/DWSWEdZOlKMkfciNhRzpqqY/npsRKNcgWl5SKB17T P/Cg1VF8e2QV9NiKYocxmB3QvZusf1K12TJW60wtKW0qlqcKi9eMHd1/PwAFVmwkbpte aBfKWJzTT4ZEoKabALrkLHi8aTYijuMh0yMzAM2TQWlbLgejwS5zWXTbS1dHAIfDlTX/ rEPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record:x-gm-message-state; bh=hTQnYIh0oYfkAKbE/YfBwKfi6ERdEfGXPntJXaKuVgk=; b=fvttSBou8xgXryL9EvyYi4356oXiGXIU3Y8VI73Xx9D1gy75cSnP7oS6ScJylbJweD A1R3ZG/UlXCIoBQAVdSAsPmxwslsCLKeRn9ycGEcxG4sUAIx7BDamFWb4hFFZmfOjs+O lu5tXwvRFpEqFKI68vuM8EyMo60Z/w7HRarbwcs/PP9vpVXJ3Q4O1hOFiyfpZrNblV9M 041sFUeGQN3WxnI9S3F422v2o5/4ukD1vX7udzoBvb2e8X98+20JNvoC+wWjzqYZnO95 jtiECQaOF9r2sDvkdW3l0UiYpQsJv+PZsLsdhelUX2wNdYteyiWerO06n7mtNuJRnwH3 lCdQ== Received: by 10.50.183.228 with SMTP id ep4mr10852593igc.74.1341391099218; Wed, 04 Jul 2012 01:38:19 -0700 (PDT) Received: by 10.50.183.228 with SMTP id ep4mr10852590igc.74.1341391099126; Wed, 04 Jul 2012 01:38:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Wed, 4 Jul 2012 01:37:58 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Wed, 4 Jul 2012 17:37:58 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=14dae934064ff7e3f504c3fcf321 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm5Kikl1lL8WEizgLoP3hy5jMbYlzLAJ1snw2ns4tEEi35MG7ha4DI+wRXFT3SSGxkmDkvkAVeu8TzXNc+u+Qo7Ez0J5SeyZ9WwTyvdRnRRl4Ent8U3SV0fvm6w1xzx3s9F+wE0PLvFgnlmeEI9D9UWDB4POG0lVnwme6n8/V+C1qBkG/c= Subject: Re: [hybi] Call for opinions on multiplexing (separate layer for multiplexing, again) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 08:38:10 -0000 --14dae934064ff7e3f504c3fcf321 Content-Type: text/plain; charset=ISO-8859-1 FYI, we can make a bit more optimization. Adopting a part of Tobias's idea in this mail http://www.ietf.org/mail-archive/web/hybi/current/msg08230.html (actually, the base idea we took was already proposed by him in this mail. I just realized...), we may allocate mux FIN bit on RSV2 to eliminate the first octet for original frames that are not first fragment. In the new draft, we disallow mux to be layered below any extension that uses per-frame signal. So, only RSV1, 2, 3 on the first fragment are meaningful. That's why we need to have only mux-FIN information on encapsulating messages for non first fragments. --14dae934064ff7e3f504c3fcf321 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI, we can make a bit more optimization.
<= div class=3D"gmail_extra">
Adopting a p= art of Tobias's idea in this mail=A0http://www.ietf.org/mail-archive/w= eb/hybi/current/msg08230.html=A0(actually, the base idea we took was al= ready proposed by him in this mail. I just realized...), we may allocate mu= x FIN bit on RSV2 to eliminate the first octet for original frames that are= not first fragment.

In the new = draft, we disallow mux to be layered below any extension that uses per-fram= e signal. So, only RSV1, 2, 3 on the first fragment are meaningful. That= 9;s why we need to have only mux-FIN information on encapsulating messages = for non first fragments.
--14dae934064ff7e3f504c3fcf321-- From tobias.oberstein@tavendo.de Sun Jul 8 15:56:39 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553BA21F875C for ; Sun, 8 Jul 2012 15:56:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twMKKZNyy1oF for ; Sun, 8 Jul 2012 15:56:38 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 33EFE21F875B for ; Sun, 8 Jul 2012 15:56:37 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.20]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Sun, 8 Jul 2012 15:57:00 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Sun, 8 Jul 2012 15:56:54 -0700 Thread-Topic: WAMP subprotocol registration Thread-Index: Ac1dE8i+2QXsPsIKQe2wF5FYTSnDCA== Message-ID: <634914A010D0B943A035D226786325D433794C8828@EXVMBX020-12.exch020.serverdata.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hybi] WAMP subprotocol registration X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 22:56:39 -0000 Hi all, How do I register a WebSocket subprotocol? We would like to register WAMP - The WebSocket Application Messaging Protocol http://wamp.ws/ WAMP is an open WebSocket subprotocol that provides two asynchronous messag= ing patterns: RPC and PubSub. There are already a number of implementations: http://wamp.ws/implementations According to http://tools.ietf.org/html/rfc6455#section-11.5 there is an "IANA registry" for such things. How? Where? The subprotocol is: Subprotocol Identifier: "wamp" Subprotocol Common Name: "The WebSocket Application Messaging Protocol" Subprotocol Definition: http://wamp.ws/spec [Note: the informal spec still needs some improvement and we plan to write = up a proper RFC ..] Cheers, Tobias From stpeter@stpeter.im Sun Jul 8 20:04:57 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD2D21F8810 for ; Sun, 8 Jul 2012 20:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCCnLDJQN0WG for ; Sun, 8 Jul 2012 20:04:57 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 18EEF21F87FD for ; Sun, 8 Jul 2012 20:04:57 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.179.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CB5134005A; Sun, 8 Jul 2012 21:23:52 -0600 (MDT) Message-ID: <4FFA4A6D.9090207@stpeter.im> Date: Sun, 08 Jul 2012 21:05:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Tobias Oberstein References: <634914A010D0B943A035D226786325D433794C8828@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: <634914A010D0B943A035D226786325D433794C8828@EXVMBX020-12.exch020.serverdata.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] WAMP subprotocol registration X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 03:04:58 -0000 On 7/8/12 4:56 PM, Tobias Oberstein wrote: > Hi all, > > How do I register a WebSocket subprotocol? > > We would like to register > > WAMP - The WebSocket Application Messaging Protocol > http://wamp.ws/ > > WAMP is an open WebSocket subprotocol that provides two asynchronous messaging patterns: RPC and PubSub. > > There are already a number of implementations: > > http://wamp.ws/implementations > > According to > > http://tools.ietf.org/html/rfc6455#section-11.5 > > there is an "IANA registry" for such things. How? Where? The policy is first come, first served. That means you can contact IANA about it directly: http://www.iana.org/cgi-bin/assignments.pl Peter -- Peter Saint-Andre https://stpeter.im/ From salvatore.loreto@ericsson.com Sun Jul 8 23:40:58 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68E711E8079 for ; Sun, 8 Jul 2012 23:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bk6FBZsHMowW for ; Sun, 8 Jul 2012 23:40:57 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD2611E807F for ; Sun, 8 Jul 2012 23:40:57 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc26d000005908-a2-4ffa7d102dfb Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 77.36.22792.01D7AFF4; Mon, 9 Jul 2012 08:41:20 +0200 (CEST) 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.3.264.0; Mon, 9 Jul 2012 08:41:20 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E58522420 for ; Mon, 9 Jul 2012 09:41:19 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C910A532E2 for ; Mon, 9 Jul 2012 09:41:20 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 566FF5324F for ; Mon, 9 Jul 2012 09:41:20 +0300 (EEST) Message-ID: <4FFA7D0E.4050401@ericsson.com> Date: Mon, 9 Jul 2012 08:41:18 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: hybi@ietf.org References: <634914A010D0B943A035D226786325D433794C8828@EXVMBX020-12.exch020.serverdata.net> <4FFA4A6D.9090207@stpeter.im> In-Reply-To: <4FFA4A6D.9090207@stpeter.im> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+Jvra5A7S9/g0UvRS3ev9zG5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujE0bawq2sVesOLOOsYGxl62LkZNDQsBE4sSDFiYIW0ziwr31 QHEuDiGBU4wSm/dcY4dw1jNK/LvRzwLhnGeU+LSmhRHCOcQo0T3nIlTZaUaJG8c2MIIM4xXQ llg+4RCYzSKgInHkbTcziM0mYCbx/OEWIJuDQ1QgWeLv/3SIckGJkzOfsIDYIkB299Y1YOXC AoYSUztmsIPYQgJVEgdmzgKLcwpoSfz++xPMZhawlbgw5zoLhC0vsf3tHGaIf9Qkrp7bxAzR qyXRe7aTaQKjyCwk62YhaZ+FpH0BI/MqRuHcxMyc9HJDvdSizOTi4vw8veLUTYzAED+45bfu DsZT50QOMUpzsCiJ83Il7fcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFiS6RAicHbTOemQ kiN/63WOvwyXeLRJtVLVTVclf/mi0D9FyQ/NFuWud7/heOjQAb4fXQ4LL7w/fIh3sdESc7/7 Cl9O7m1l7E+rYdpc/N85Ys6f97qxW5fqTdoc/6xv+33r03LSIZfzF03M0OcKq2Ra3Tg/+bbb fOGpGYWKOnK+zULXkqYuYFBiKc5INNRiLipOBAC1fNvBPwIAAA== Subject: Re: [hybi] WAMP subprotocol registration X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 06:40:58 -0000 On 7/9/12 5:05 AM, Peter Saint-Andre wrote: > On 7/8/12 4:56 PM, Tobias Oberstein wrote: >> Hi all, >> >> How do I register a WebSocket subprotocol? >> >> We would like to register >> >> WAMP - The WebSocket Application Messaging Protocol >> http://wamp.ws/ >> >> WAMP is an open WebSocket subprotocol that provides two asynchronous messaging patterns: RPC and PubSub. >> >> There are already a number of implementations: >> >> http://wamp.ws/implementations >> >> According to >> >> http://tools.ietf.org/html/rfc6455#section-11.5 >> >> there is an "IANA registry" for such things. How? Where? > The policy is first come, first served. That means you can contact IANA > about it directly: > > http://www.iana.org/cgi-bin/assignments.pl the Iana WebSocket Protocol Registries is here: http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name Salvatore -- Salvatore Loreto, PhD www.sloreto.com From derhoermi@gmx.net Sun Jul 8 23:44:12 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1CB11E807F for ; Sun, 8 Jul 2012 23:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=-2.667, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yO09eKZioUJ for ; Sun, 8 Jul 2012 23:44:11 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id BF18711E8079 for ; Sun, 8 Jul 2012 23:44:10 -0700 (PDT) Received: (qmail invoked by alias); 09 Jul 2012 06:44:33 -0000 Received: from dslb-094-222-148-074.pools.arcor-ip.net (EHLO netb) [94.222.148.74] by mail.gmx.net (mp024) with SMTP; 09 Jul 2012 08:44:33 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+RLjYKpJiRFpVy9WviEFj9HsnvMzKOelro9HNhDQ K34qMqIsea5qs5 From: Bjoern Hoehrmann To: Tobias Oberstein Date: Mon, 09 Jul 2012 08:44:34 +0200 Message-ID: <9bvkv7h55c40so8j1mkkq5osekkqsli33v@hive.bjoern.hoehrmann.de> References: <634914A010D0B943A035D226786325D433794C8828@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: <634914A010D0B943A035D226786325D433794C8828@EXVMBX020-12.exch020.serverdata.net> 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] WAMP subprotocol registration X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 06:44:12 -0000 * Tobias Oberstein wrote: >According to > >http://tools.ietf.org/html/rfc6455#section-11.5 > >there is an "IANA registry" for such things. How? Where? http://www.iana.org/assignments/websocket has all the registries. -- 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 tyoshino@google.com Tue Jul 10 02:23:19 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE87F21F8600 for ; Tue, 10 Jul 2012 02:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.965 X-Spam-Level: X-Spam-Status: No, score=-102.965 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMlXxPmLTtRy for ; Tue, 10 Jul 2012 02:23:19 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8D921F85FD for ; Tue, 10 Jul 2012 02:23:18 -0700 (PDT) Received: by yhq56 with SMTP id 56so317005yhq.31 for ; Tue, 10 Jul 2012 02:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Maka8G0g5MqwAy3wrgBxSdAzCgoFxc4PVati+PwclYc=; b=iJ2K2u45jJXLvUK5HeWvgL6vClatrg0m5ihxfo2FXz0rLoiLeQKlOzcsKMXEuQj+lY AY6dN1QYqJD/Vx4S1/1JhGFIIbHEVTxXy1Zlp7di4Q+m7RXvSdE0vLpIbLEXE/F2WKrb 7PX/1VKUn5lNjjtAZlxXdl823+0RQK8k1B6xdcLsYHuD/yMDo2eHOctQw/TlZF/Ymh7n uOzOC1mWnsKZR34fQvcOBN5mx8iBKxkFRJJP28FtCTn+ihl1A5+EHSvxOLyDos8NhVGY ngBGeGG+aAjO+YxptSOrHRqhpLJmjGH3yHtz0xVO1G1U46C1T4lkvfJOPFWZq38+xQh3 j/+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Maka8G0g5MqwAy3wrgBxSdAzCgoFxc4PVati+PwclYc=; b=JD+enK8i6cYaTAgitysylJ7eUhggKq5vn+UDXVKDHVA5OyLivr/maSiOacST4k09ZC x5NUdPe8032xB+EMn8Ni4O4FD/eTYX38KVoyiFaOXuhYIirOfqMe/NoAYY3ha1QuQz77 LMD4EgTepfIPT1TbtPFdD6Yay4gF3KZs5ODEeMuZBsZyVAD0CXGoQs1tmxY2e+oq9pji BPoJEd036U0g4B8T+4OExeH75hrFbr15BTpoFdAfxSItixWSNciHD0VLvMbQxTkasSfI eNk+fQq0OljEwAQ6eyqH16VPfXa2fwy6D1Vne+YVaeT7lyn+VMkYYkesSU85rcdIwrMV UXUA== Received: by 10.42.155.73 with SMTP id t9mr22185547icw.48.1341912225669; Tue, 10 Jul 2012 02:23:45 -0700 (PDT) Received: by 10.42.155.73 with SMTP id t9mr22185539icw.48.1341912225546; Tue, 10 Jul 2012 02:23:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Tue, 10 Jul 2012 02:23:25 -0700 (PDT) In-Reply-To: <4FEA3A97.5030301@caucho.com> References: <4FEA3A97.5030301@caucho.com> From: Takeshi Yoshino Date: Tue, 10 Jul 2012 18:23:25 +0900 Message-ID: To: ferg@caucho.com Content-Type: multipart/alternative; boundary=90e6ba61358a8603c004c4764924 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlgcJafJCyH8dgQQMYx/bR5iRcLLBj4RA1Q06e0CaGcaX4+sQc3zivAo/Rvn6iW22NSl0iP7ue0KwnLeq7uEjvizZo0Oo6bUEKkIvWQRDPyBrAqoav2+lBhU3V8FpztnsFlSAcU67jtWdXPY4CLMWZOWYPY3xYZq6basZpLMy3mfF3L1EE= Cc: "hybi@ietf.org" Subject: Re: [hybi] Multiplexing: even/odd client/server channel open X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 09:23:19 -0000 --90e6ba61358a8603c004c4764924 Content-Type: text/plain; charset=ISO-8859-1 Hi Scott, On Wed, Jun 27, 2012 at 7:41 AM, Scott Ferguson wrote: > In the current draft, only the client can open channels and it can open > any channel id. > > In http-ng (and spdy, I believe), half the channel ids (even) are reserved > to the client and half the channel ids (odd) are reserved to the server. > > This splitting of the channel space allows either end to open a new > channel without collision. Since spdy is already experimenting with the use > of server-initiated channels, it's not unreasonable to suppose that some > websocket applications may want similar capabilities. (Presumably > non-browser apps or spdy-over-websocket.) > > Alternatively, the odd channels could be reserved for future expansion > without adding server-initiated channels now, allowing a later version of > mux to add server-initiated channels. > Thanks for suggestion. I think it's easy to take in your idea. The only loss is that we'll take more overhead for channel ID field 2 times earlier. But in practice, we need some more spec text, more error handling for when an invalid channel ID is received. SPDY has real use case (server push). WebSocket doesn't for now. We can define mux v2 with such a rule for ID when server-initiated channel is necessary. Even if we reserve odd (or even) numbers for future use, endpoints need to be re-implemented to generate/understand server-initiated channel creation commands. Anyone interested in this or objects to this? If S+M adopts WebSocket multiplexing for its multiplexing method, and adopts server push transactions idea, it would be one real use case, maybe. > I didn't see a previous discussion on this topic, but I skimmed fairly > quickly, so disregard if it's been discussed already. > You're right. --90e6ba61358a8603c004c4764924 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Scott,

On Wed, Jun 27, 2012 at 7:41 AM, Scott Ferguso= n <ferg@caucho.com> wrote:
In the current draft, only the client can op= en channels and it can open any channel id.

In http-ng (and spdy, I believe), half the channel ids (even) are reserved = to the client and half the channel ids (odd) are reserved to the server.
This splitting of the channel space allows either end to open a new channel= without collision. Since spdy is already experimenting with the use of ser= ver-initiated channels, it's not unreasonable to suppose that some webs= ocket applications may want similar capabilities. (Presumably non-browser a= pps or spdy-over-websocket.)
=A0
Alternatively, the odd channels could be reserved for future expansion with= out adding server-initiated channels now, allowing a later version of mux t= o add server-initiated channels.

Thanks for suggestion.

I think it's easy to ta= ke in your idea. The only loss is that we'll take more overhead for cha= nnel ID field 2 times earlier.

But in practice, we= need some more spec text, more error handling for when an invalid channel = ID is received. SPDY has real use case (server push). WebSocket doesn't= for now. We can define mux v2 with such a rule for ID when server-initiate= d channel is necessary. Even if we reserve odd (or even) numbers for future= use, endpoints need to be re-implemented to generate/understand server-ini= tiated channel creation commands.

Anyone interested in this or objects to this?

If S+M adopts WebSocket multiplexing for its multiplexing m= ethod, and adopts server push transactions idea, it would be one real use c= ase, maybe.
=A0
Date: Tue, 10 Jul 2012 16:51:53 -0400 Message-ID: To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=f46d04447f6daf591404c47fe7d6 X-Gm-Message-State: ALoCoQlSE/aAK3kTEVBwnahkUt6CYttwLuY3YwOqu2T2bLTCpojpoWNqlZKV9/oWHjPlBf8V30/8 Cc: "hybi@ietf.org" Subject: Re: [hybi] Multiplexing: even/odd client/server channel open X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 20:51:46 -0000 --f46d04447f6daf591404c47fe7d6 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 10, 2012 at 5:23 AM, Takeshi Yoshino wrote: > Thanks for suggestion. > > I think it's easy to take in your idea. The only loss is that we'll take > more overhead for channel ID field 2 times earlier. > > But in practice, we need some more spec text, more error handling for when > an invalid channel ID is received. SPDY has real use case (server push). > WebSocket doesn't for now. We can define mux v2 with such a rule for ID > when server-initiated channel is necessary. Even if we reserve odd (or > even) numbers for future use, endpoints need to be re-implemented to > generate/understand server-initiated channel creation commands. > > Anyone interested in this or objects to this? > > If S+M adopts WebSocket multiplexing for its multiplexing method, and > adopts server push transactions idea, it would be one real use case, maybe. > WebSockets currently only has support for the client initiating a connection, and it is hard to imagine that changing. I don't see any reason that muxing channels should change that. -- John A. Tamplin --f46d04447f6daf591404c47fe7d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 10, 2012 at 5:23 AM, Takeshi Yoshino= <tyoshino@google.com> wrote:
Thanks for = suggestion.

I think it's easy to take in your = idea. The only loss is that we'll take more overhead for channel ID fie= ld 2 times earlier.

But in practice, we need some more spec text, more erro= r handling for when an invalid channel ID is received. SPDY has real use ca= se (server push). WebSocket doesn't for now. We can define mux v2 with = such a rule for ID when server-initiated channel is necessary. Even if we r= eserve odd (or even) numbers for future use, endpoints need to be re-implem= ented to generate/understand server-initiated channel creation commands.

Anyone interested in this or objects to this?

If S+M adopts WebSocket multiplexing for its multiplexing m= ethod, and adopts server push transactions idea, it would be one real use c= ase, maybe.

WebSockets currently onl= y has support for the client initiating a connection, and it is hard to ima= gine that changing. =C2=A0I don't see any reason that muxing channels s= hould change that.=C2=A0

--
John A. Tamplin
--f46d04447f6daf591404c47fe7d6-- From gregw@intalio.com Thu Jul 12 13:29:39 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22BD11E8096 for ; Thu, 12 Jul 2012 13:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LA2zSu37yE3 for ; Thu, 12 Jul 2012 13:29:38 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0456B11E8080 for ; Thu, 12 Jul 2012 13:29:37 -0700 (PDT) Received: by qaea16 with SMTP id a16so1930126qae.10 for ; Thu, 12 Jul 2012 13:30:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=bqnqgyL9+idrwgDAgBBtjZqiOYbq++OXAFTI2nRBCok=; b=OEAYuBfOQmZZpKNveBTH7bAIAECJmCgSMCRjiSVYM3zy2ar18v7kzjnpxy4zka64Uo 9aOuc+TGXtxeBEJ+R7r+9CLcilh5kJ2BY2wI+RGBhANmQMI7kMyEdMmKO/Z3z3sZ/cHr G9yP9Ia44FhkF6qw1HLQ3L+t3rtkcbvcsjWF6sYzhgvoPOFL49p02gfBxxwjGPbPLL9u 8dCpFUq68pcSMxql8tuSP+FTvF0lQcxdTYVRjMS+MIzcVNz4/VJoClUt+DYLCZ5Rk8hN DCEpuLhGJe/72L6auH/BcgU3S+owrvjCMSIROVCZhyxlKZPP0I2QkQ1nuSDdcwMQkyfq 9j4Q== MIME-Version: 1.0 Received: by 10.229.135.198 with SMTP id o6mr18158806qct.147.1342125011562; Thu, 12 Jul 2012 13:30:11 -0700 (PDT) Received: by 10.229.84.144 with HTTP; Thu, 12 Jul 2012 13:30:11 -0700 (PDT) In-Reply-To: References: <4FEA3A97.5030301@caucho.com> Date: Thu, 12 Jul 2012 22:30:11 +0200 Message-ID: From: Greg Wilkins To: "John A. Tamplin" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlCtC9DZsel1YJ5DFvHeR7U2B/K6Gjf2jja8dO1IN57Xnkh39D+zkbFdSAl542BV/qUqs7x Cc: "hybi@ietf.org" Subject: Re: [hybi] Multiplexing: even/odd client/server channel open X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 20:29:39 -0000 On 10 July 2012 22:51, John A. Tamplin wrote: > WebSockets currently only has support for the client initiating a > connection, and it is hard to imagine that changing. I don't see any reason > that muxing channels should change that. There is already a proposal in front of HTTPbis working group that uses websocket as the framing layer for HTTP/2.0 with a SPDY like layer on top. So it is not beyond the imagination that websockets might one day need to support this. Making the small investment now in saying client open channels are odd/even might be a wise investment. However I don't think we need to fully specify server opened channels just yet. cheers -- Greg Wilkins www.webtide.com Developer advice, services and support from the Jetty & CometD experts. From tyoshino@google.com Tue Jul 17 23:31:52 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581CE11E8146 for ; Tue, 17 Jul 2012 23:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngAdZNLwL6v0 for ; Tue, 17 Jul 2012 23:31:51 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5809A11E8143 for ; Tue, 17 Jul 2012 23:31:51 -0700 (PDT) Received: by yhq56 with SMTP id 56so1356590yhq.31 for ; Tue, 17 Jul 2012 23:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record; bh=FLalrDLkqe3iGmnIR2oH6tfpbu+RV+Z5F8IxTy2b1Ik=; b=kl6x7fK2Khr5TooaFx3jGrEAeWVFOx3kVSWzeaYBBz6MxdEhH9bxk21rQk5SH9cNHD V/ljRPw6mHzaazOPGOylpCRgLr8h+cCjmP/zBe1iTqm/2OuC3yJ7dJ3VNT6sKM3xtqKG Je3fzq7kl3E65CG+vJ1lUifyTzNuYNw5oX0+XuQbHXwjGIJg7Q3TkhickNWGMGXTxn/j sjRea5/YIt+Yuxb7rs+FyStwITmsqij3C5rQ7w8GT3KQYkBvJAIV3mH2jXIZrQQ3gKBN SqhJFYlF9owuVYVV0izko1vL2sa0vG/eUpa1xlfsOB0reD2gmlNI9x5dVjs8sT0eLB+5 41Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record:x-gm-message-state; bh=FLalrDLkqe3iGmnIR2oH6tfpbu+RV+Z5F8IxTy2b1Ik=; b=lEt4g1nVfWGPhgOpfzL81pnGrSyCHzo7+ggobKp3+YzhpjFFclJ9pgcTBVfSDyzo2Z wd59v/bVbb6Q3PLdoJ13meH8CpwmJuKka23kW/H1TRPmNUh8mFhtJI6/ar/7wOzixgUN 1zbj5hOeR4f6xWpgwS+0+PAGxuDMLim4yvEx+efHfaJYMfhAnveDUeEtvN+EthpXU24I n1Riqr0Lj4HQOLjytZQZ2sLEsAoV4954qt8CNJbwbRjhkQmJW/iwUEw3KuMKMvoYmRRS Tp/sKMyvx17q46EAtbxqgNdL4NB1DuEio9YpO6OifScOvrLlGSMgtrIBBZSo4GrYPhSl winQ== Received: by 10.50.140.70 with SMTP id re6mr985238igb.23.1342593160250; Tue, 17 Jul 2012 23:32:40 -0700 (PDT) Received: by 10.50.140.70 with SMTP id re6mr985235igb.23.1342593160164; Tue, 17 Jul 2012 23:32:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Tue, 17 Jul 2012 23:32:19 -0700 (PDT) In-Reply-To: References: <20120704075951.24580.48630.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Wed, 18 Jul 2012 15:32:19 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=e89a8f923b9c63b6ff04c514d41c X-System-Of-Record: true X-Gm-Message-State: ALoCoQkUJoMgDjGyukfBb4st1xuBcO+9sLePvKd/n+LKiRlM6bA6cPeY6jGoNzJt6zkMhBacj4V1q0i1nw/cSU7MNT6jJmvHzskIBiK/Vno5MnCBOpNwDT4Zecxf7Z3grwRci6Ttzj2Np+svNnkm01vUCn1l1Cd28xnv/ve1Xb87qHgHw/bK1z8= Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-03.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 06:31:52 -0000 --e89a8f923b9c63b6ff04c514d41c Content-Type: text/plain; charset=ISO-8859-1 I'm planning to make small change on quota spending rule. Now quota mechanism considers only the length of payload data. This allows a bad logical channel to flood the connection with zero-sized messages. I'll add kinda penalty of 1 octet quota consumption to each encapsulated message in addition to its payload data length. So, a message "Hello" spends 6 byte of send quota. If fragmented like "Hel" "lo", still spends 6 byte. An empty message spends 1 byte. I'm going to add just 1 byte tax to each message, not each encapsulated frame. Multiplexing may fragment messages to fit remaining quota. If fragmentation also affects quota consumption, implementation would be complicated. Thoughts? --e89a8f923b9c63b6ff04c514d41c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm planning to make small change on quota spending rule.

Now quota mechanism considers only the length of payload data. This a= llows a bad logical channel to flood the connection with zero-sized message= s. I'll add=A0kinda penalty of 1 octet quota consumption to each encaps= ulated message in addition to its payload data length.

So, a message "Hello" spends 6 byte of send q= uota. If fragmented like "Hel" "lo", still spends 6 byt= e. An empty message spends 1 byte.

I'm going t= o add just 1 byte tax to each message, not each encapsulated frame. Multipl= exing may fragment messages to fit remaining quota. If fragmentation also a= ffects quota consumption, implementation would be complicated.

Thoughts?
--e89a8f923b9c63b6ff04c514d41c-- From duerst@it.aoyama.ac.jp Wed Jul 18 00:27:31 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E26F21F84EA for ; Wed, 18 Jul 2012 00:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.245 X-Spam-Level: X-Spam-Status: No, score=-100.245 tagged_above=-999 required=5 tests=[AWL=-0.455, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qL38tfXWjlt6 for ; Wed, 18 Jul 2012 00:27:30 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 44B9421F84E6 for ; Wed, 18 Jul 2012 00:27:29 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q6I7S9bQ003902 for ; Wed, 18 Jul 2012 16:28:09 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 2d08_e815_1ff157ac_d0aa_11e1_979b_001d096c5782; Wed, 18 Jul 2012 16:28:09 +0900 Received: from [IPv6:::1] ([133.2.210.1]:54104) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 18 Jul 2012 16:28:13 +0900 Message-ID: <50066583.6030902@it.aoyama.ac.jp> Date: Wed, 18 Jul 2012 16:28:03 +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: Takeshi Yoshino References: <20120704075951.24580.48630.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-03.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 07:27:31 -0000 Hello Takeshi, On 2012/07/18 15:32, Takeshi Yoshino wrote: > I'm planning to make small change on quota spending rule. > > Now quota mechanism considers only the length of payload data. This allows > a bad logical channel to flood the connection with zero-sized messages. > I'll add kinda penalty of 1 octet quota consumption to each encapsulated > message in addition to its payload data length. > > So, a message "Hello" spends 6 byte of send quota. If fragmented like "Hel" > "lo", still spends 6 byte. An empty message spends 1 byte. > > I'm going to add just 1 byte tax to each message, not each encapsulated > frame. Multiplexing may fragment messages to fit remaining quota. If > fragmentation also affects quota consumption, implementation would be > complicated. What about an attacker fragmenting messages on purpose? And why adding 1? Why not add the actual header length, which is the actual cost? Regards, Martin. From tyoshino@google.com Wed Jul 18 00:53:22 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E9921F8741 for ; Wed, 18 Jul 2012 00:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.816 X-Spam-Level: X-Spam-Status: No, score=-102.816 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYMR5+8QRD2d for ; Wed, 18 Jul 2012 00:53:21 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B53AB21F8726 for ; Wed, 18 Jul 2012 00:53:09 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1411706ghb.31 for ; Wed, 18 Jul 2012 00:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=QcrZcHWW1Y5kf8v5hEfTA57uIgXzIDkfEIYFk03hZ0M=; b=AV3yoTy8Hr5u+WPi7Vq80nTsCb41pl4ikX9GaA+4nyWIv6yZRXz+bDgvfkcd+xeryb BvNNNLUkkOfBrbg/LifVnnwyhNsI5XwYI5hNishXMdsQ9ihx6p/KbIFfNkHPrmlkf0sz fQZBEe1fxTsmwWcuTWyYB4/UiXTV8sQotG1alnoc61EkQg4JWd15vpOTVge5XjfvSM1t 9BsFrKhpMuSFj5vM0edeNlEaF69RpSNRXpefVu/ITN54VpDvVam3vyQn0oPXM0TTnxtv fp/JJNRrc81x7My1TlgW/YjmEVTP7j8RDyptGWF0pK+LU1GDesRA3jhVb8EoYkWfo+2R TheQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=QcrZcHWW1Y5kf8v5hEfTA57uIgXzIDkfEIYFk03hZ0M=; b=dg7ZKb1lhTUGHEEybUg7spfLrBtp5ozBUo+e3kpyjeuVszAMzzOSaukA1fE3qykbrp z8tXH7lKtIeEppN9oKvRJkxv4OomqEGBxhPhXIqjA8DdUKZF8fz/cepPIr2rNjxrxO9B 8bslq1qQ/sdJzQY8BetkDT5Kv4GF1nBLQe7pA717IuMM37M+cNdLGr89zoTpPHBFFVfj /66XHUiHU3LnTc+IoHyhndezyHjnxa5yLSOhF4EWfQ4xpoxqCNcQK6yX2d7i/aDTGzGh qIpDn+XN4365VDpACMDAdLEUT6IKyOGOyZ867hykiQo34b3JrNJMC+2JtvPOzYqOYa4D rxjA== Received: by 10.50.149.225 with SMTP id ud1mr1042769igb.74.1342598038744; Wed, 18 Jul 2012 00:53:58 -0700 (PDT) Received: by 10.50.149.225 with SMTP id ud1mr1042762igb.74.1342598038657; Wed, 18 Jul 2012 00:53:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Wed, 18 Jul 2012 00:53:38 -0700 (PDT) In-Reply-To: <50066583.6030902@it.aoyama.ac.jp> References: <20120704075951.24580.48630.idtracker@ietfa.amsl.com> <50066583.6030902@it.aoyama.ac.jp> From: Takeshi Yoshino Date: Wed, 18 Jul 2012 16:53:38 +0900 Message-ID: To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: multipart/alternative; boundary=e89a8f3baf032b9a5704c515f725 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm9QWcyu/OLJnt3WyBvlgqqKKxoe/r7BEwlf5XMZ3kf5Yutv+zatkhWdjDXnmhfrNHRMX5L4hCVdwpqM7GNx8BUKodFtNTFJqmyGJ3ieswWHpZHBbSUK3BZOBR+OkVaCTT/J2r1AcU+rKaP6BPrn6wJwff9z4U92j4qMBTsBKb1/dvTDlc= Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-03.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 07:53:23 -0000 --e89a8f3baf032b9a5704c515f725 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Martin, On Wed, Jul 18, 2012 at 4:28 PM, "Martin J. D=FCrst" wrote: > Hello Takeshi, > > > On 2012/07/18 15:32, Takeshi Yoshino wrote: > >> I'm planning to make small change on quota spending rule. >> >> Now quota mechanism considers only the length of payload data. This allo= ws >> a bad logical channel to flood the connection with zero-sized messages. >> I'll add kinda penalty of 1 octet quota consumption to each encapsulated >> message in addition to its payload data length. >> >> So, a message "Hello" spends 6 byte of send quota. If fragmented like >> "Hel" >> "lo", still spends 6 byte. An empty message spends 1 byte. >> >> I'm going to add just 1 byte tax to each message, not each encapsulated >> frame. Multiplexing may fragment messages to fit remaining quota. If >> fragmentation also affects quota consumption, implementation would be >> complicated. >> > > What about an attacker fragmenting messages on purpose? Multiplexer may de-fragment them (e.g. zero-sized message as 10000 frames) into smaller number of frames. When interleaved with control frames, each control frame also consumes 1+ byte quota. > And why adding 1? Why not add the actual header length, which is the > actual cost? > To address the dead lock concern perfectly, I thought it's better not to spend quota more than 1 byte for the minimum unit of transmission. As it's up to 10 byte, I agree it wouldn't be a big problem like the per-frame compression's fragmentation lock issue. Using the length of the original header may be also fine. --e89a8f3baf032b9a5704c515f725 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Martin,

On Wed, Jul 18, 2012 at 4:28 PM, &qu= ot;Martin J. D=FCrst" <duerst@it.aoyama.ac.jp> wro= te:
Hello Takeshi,


On 2012/07/18 15:32, Takeshi Yoshino wrote:
I'm planning to make small change on quota spending rule.

Now quota mechanism considers only the length of payload data. This allows<= br> a bad logical channel to flood the connection with zero-sized messages.
I'll add kinda penalty of 1 octet quota consumption to each encapsulate= d
message in addition to its payload data length.

So, a message "Hello" spends 6 byte of send quota. If fragmented = like "Hel"
"lo", still spends 6 byte. An empty message spends 1 byte.

I'm going to add just 1 byte tax to each message, not each encapsulated=
frame. Multiplexing may fragment messages to fit remaining quota. If
fragmentation also affects quota consumption, implementation would be
complicated.

What about an attacker fragmenting messages on purpose?
Multiplexer may de-fragment them (e.g. zero-sized message as 1= 0000 frames) into smaller number of frames. When interleaved with control f= rames, each control frame also consumes 1+ byte quota.
=A0
And why adding 1? Why not add= the actual header length, which is the actual cost?
<= br>
To address the dead lock concern perfectly, I thought it's b= etter not to spend quota more than 1 byte for the minimum unit of transmiss= ion.

As it's up to 10 byte, I agree it wou= ldn't be a big problem like the=A0per-frame compression's=A0fragmen= tation lock issue.=A0Using the length of the original header may be also fi= ne.

--e89a8f3baf032b9a5704c515f725-- From arman@noemax.com Wed Jul 18 01:09:12 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C523921F861B for ; Wed, 18 Jul 2012 01:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWcecxHPENu8 for ; Wed, 18 Jul 2012 01:09:12 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id D424421F861C for ; Wed, 18 Jul 2012 01:09:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1342599001; x=1343203801; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=E5AQWCXJT8iHvKSFCeoRr0bHnFw=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=2gmE6wejv31tJetbIIyMcpCAk+LK/COlsfgqM79cOEzpoyRyrzoehQfxdPf9JNNzgzRJREJXJjuPqaa9X/6qLZootpsOngxo38ZFqc4CZM8vVESCV9mgMZzkmsPrqiR/bIl3mju4wr70+idtTSqTjdnXNnWHdgtkKAB6En9q640= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id CPC13700; Wed, 18 Jul 2012 11:10:00 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" , =?iso-8859-1?Q?'Martin_J._D=FCrst'?= References: <20120704075951.24580.48630.idtracker@ietfa.amsl.com> <50066583.6030902@it.aoyama.ac.jp> In-Reply-To: Date: Wed, 18 Jul 2012 11:09:27 +0300 Message-ID: <00af01cd64bc$ab1c72d0$01555870$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01CD64D5.D06B0A60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHuGCaP9TEvjtExVNsNU5IRw9J4kgGvMepYAaeu7PMCt735NQEoprN3lrOOVKA= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-03.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 08:09:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B0_01CD64D5.D06B0A60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If we would envelope the entire traffic produced by the logical channel (complete frames including headers) then we would not have this problem, plus WS mux would be able to multiplex any protocol (e.g. SPDY) and not = only WebSocket frames. =20 WBR, Arman =20 =20 From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino Sent: Wednesday, July 18, 2012 10:54 AM To: Martin J. D=FCrst Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-03.txt =20 Hello Martin, =20 On Wed, Jul 18, 2012 at 4:28 PM, "Martin J. D=FCrst" = wrote: Hello Takeshi, On 2012/07/18 15:32, Takeshi Yoshino wrote: I'm planning to make small change on quota spending rule. Now quota mechanism considers only the length of payload data. This = allows a bad logical channel to flood the connection with zero-sized messages. I'll add kinda penalty of 1 octet quota consumption to each encapsulated message in addition to its payload data length. So, a message "Hello" spends 6 byte of send quota. If fragmented like = "Hel" "lo", still spends 6 byte. An empty message spends 1 byte. I'm going to add just 1 byte tax to each message, not each encapsulated frame. Multiplexing may fragment messages to fit remaining quota. If fragmentation also affects quota consumption, implementation would be complicated. =20 What about an attacker fragmenting messages on purpose? =20 Multiplexer may de-fragment them (e.g. zero-sized message as 10000 = frames) into smaller number of frames. When interleaved with control frames, = each control frame also consumes 1+ byte quota. =20 And why adding 1? Why not add the actual header length, which is the = actual cost? =20 To address the dead lock concern perfectly, I thought it's better not to spend quota more than 1 byte for the minimum unit of transmission. =20 As it's up to 10 byte, I agree it wouldn't be a big problem like the per-frame compression's fragmentation lock issue. Using the length of = the original header may be also fine. =20 ------=_NextPart_000_00B0_01CD64D5.D06B0A60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If we = would envelope the entire traffic produced by the logical channel = (complete frames including headers) then we would not have this problem, = plus WS mux would be able to multiplex any protocol (e.g. SPDY) and not = only WebSocket frames.

 

WBR,

Arman

 

 

From:= = hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = Takeshi Yoshino
Sent: Wednesday, July 18, 2012 10:54 = AM
To: Martin J. D=FCrst
Cc: = hybi@ietf.org
Subject: Re: [hybi] I-D Action: = draft-ietf-hybi-websocket-multiplexing-03.txt

 

Hello = Martin,

 

On = Wed, Jul 18, 2012 at 4:28 PM, "Martin J. D=FCrst" <duerst@it.aoyama.ac.jp> = wrote:

Hello = Takeshi,



On = 2012/07/18 15:32, Takeshi Yoshino wrote:

I'm planning to make small change on quota spending = rule.

Now quota mechanism considers only the length of payload = data. This allows
a bad logical channel to flood the connection with = zero-sized messages.
I'll add kinda penalty of 1 octet quota = consumption to each encapsulated
message in addition to its payload = data length.

So, a message "Hello" spends 6 byte of = send quota. If fragmented like "Hel"
"lo", still = spends 6 byte. An empty message spends 1 byte.

I'm going to add = just 1 byte tax to each message, not each encapsulated
frame. = Multiplexing may fragment messages to fit remaining quota. = If
fragmentation also affects quota consumption, implementation would = be
complicated.

 

What about an attacker fragmenting messages on = purpose?

 

Multiplexer may de-fragment them (e.g. zero-sized = message as 10000 frames) into smaller number of frames. When interleaved = with control frames, each control frame also consumes 1+ byte = quota.

 

And why = adding 1? Why not add the actual header length, which is the actual = cost?

 

To address the dead lock concern perfectly, I thought = it's better not to spend quota more than 1 byte for the minimum unit of = transmission.

 

As it's up to 10 byte, I agree it wouldn't be a big = problem like the per-frame compression's fragmentation lock = issue. Using the length of the original header may be also = fine.

 

------=_NextPart_000_00B0_01CD64D5.D06B0A60-- From tyoshino@google.com Wed Jul 18 21:38:48 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B17611E8093 for ; Wed, 18 Jul 2012 21:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.961 X-Spam-Level: X-Spam-Status: No, score=-102.961 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyIk9AnQgbNU for ; Wed, 18 Jul 2012 21:38:47 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4301211E8091 for ; Wed, 18 Jul 2012 21:38:45 -0700 (PDT) Received: by yhq56 with SMTP id 56so2594638yhq.31 for ; Wed, 18 Jul 2012 21:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=UcDWfB5AedWjj05/cRAYvsROi28njiXo9+XYSLZR0d4=; b=Bzfjt+5PlCRWc/XvKnHKOyKOuyb6/87P/cFe89dcOyQ4gT/YlBnfAe80K68DmMOy01 lXrm1MtyixG8toEsY3Q2ngptE0XoJhNMIJ1z+WvvfUoZKfx8Ec5Pi7PASxvMzIq2JIRN czGwBNusiIv6ElDaYQAgtrZnv/MlxS81I+GP2VwMg5NpJVfpNpgmcwunhSBUHDRqGPJC gOf6CQung/a7yMq0RAe6+TVY+I2ZRRcQL68BxtPita+8IuExbM7OiT2bYNAbidAR8e0+ CcJl1jDUTrYdYZZ/tnzJ1e9sg74vSU1P1Sjai+SUCxzGG8TILrTrD1qwnhKoaGLHe81f O0Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=UcDWfB5AedWjj05/cRAYvsROi28njiXo9+XYSLZR0d4=; b=YE974vTkElVWrK82YKwEMKyVgNLiH6Kiq4ez2cTgz9wwcMSMv+EERAdG3su2z3DAru jcM0GpAPQztGkePc/vEgKFZMUWAxpdi5aznFpDnxlQPz+AbUfx89z0c9WJNubfu8rkFt M8T4vyHzFwtZIPvzxoCozKMTt169BiBRAbCU5jeEenAySYxgn7rDnSIIJXkMndFSBo9u P7oA7ga0INjrQXRySU2LqL1WkQkwlPbD6cG0L7iZq9b4IWw6ae1+G6nGWvs0uopzJvwp jPOFxZ68TZF/5OwxK5iWrLDmtzDpzWKOCszgAWOMdNPWed4XzrU+P/38vrgS2KQOKfLY eXLA== Received: by 10.50.41.195 with SMTP id h3mr195988igl.34.1342672776633; Wed, 18 Jul 2012 21:39:36 -0700 (PDT) Received: by 10.50.41.195 with SMTP id h3mr195980igl.34.1342672776516; Wed, 18 Jul 2012 21:39:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Wed, 18 Jul 2012 21:39:15 -0700 (PDT) In-Reply-To: References: <4FEA3A97.5030301@caucho.com> From: Takeshi Yoshino Date: Thu, 19 Jul 2012 13:39:15 +0900 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=14dae934051de4d60204c5275dc3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlG1aijb75IDlsULKR9cOFf5DYq1YBbBEe7Ff2XtbZQ1SUpaB2833dGqZOMjwDMMFaFH+wlVn+98mzziZxKindSabkp8sUZ6zVw2fqp9NDjJiZJARgd98OzL95Ffxs5049L9ltK7yM18MmkStJvhf3sw6lfTDJpWMDBZfTxKJwbPXlOC60= Cc: "hybi@ietf.org" Subject: Re: [hybi] Multiplexing: even/odd client/server channel open X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 04:38:48 -0000 --14dae934051de4d60204c5275dc3 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 13, 2012 at 5:30 AM, Greg Wilkins wrote: > On 10 July 2012 22:51, John A. Tamplin wrote: > > WebSockets currently only has support for the client initiating a > > connection, and it is hard to imagine that changing. I don't see any > reason > > that muxing channels should change that. > > There is already a proposal in front of HTTPbis working group that > uses websocket as the framing layer for HTTP/2.0 with a SPDY like > layer on top. So it is not beyond the imagination that websockets > might one day need to support this. > > Making the small investment now in saying client open channels are > odd/even might be a wise investment. However I don't think we need to > fully specify server opened channels just yet. > > I think it's not too late that the client decides to spare odd/even channel ID for server-initiated stream after getting agreement on use of server-initiated stream on the opening handshake for the physical connection (e.g. exchanging "Sec-WebSocket-Extensions: mux; server-initiated"). Reserving odd/even channel ID from now makes sense if we won't (can't) make a change on extension negotiation like this, but just add new multiplex control block types to enable server-initiated stream feature (old mux implementations ignore them and maybe send some block to tell NOT_IMPLEMENTED error). But I believe that this kind of feature negotiation should be done on physical connection opening handshake, not when receiving a multiplex control block. --14dae934051de4d60204c5275dc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 13, 2012 = at 5:30 AM, Greg Wilkins <gregw@intalio.com> wrote:
On 10 July 2012 22:51, John A. Tamplin <jat@jaet.org> wrote:
> WebSockets currently only has support for the client initiating a
> connection, and it is hard to imagine that changing. =A0I don't se= e any reason
> that muxing channels should change that.

There is already a proposal in front of HTTPbis working group that uses websocket as the framing layer for HTTP/2.0 with a SPDY like
layer on top. =A0 =A0So it is not beyond the imagination that websockets might one day need to support this.

Making the small investment now in saying client open channels are
odd/even might be a wise investment. =A0However I don't think we need t= o
fully specify server opened channels just yet.

I think it's not too late that the client decides to spare = odd/even channel ID for server-initiated stream after getting agreement on = use of server-initiated stream on the opening handshake for the physical co= nnection (e.g. exchanging "Sec-WebSocket-Extensions: mux; server-initi= ated").

Reserving odd/even channel ID from now makes sense if w= e won't (can't) make a change on extension negotiation like this, b= ut just add new multiplex control block types to enable server-initiated st= ream feature (old mux implementations ignore them and maybe send some block= to tell NOT_IMPLEMENTED error). But I believe that this kind of feature ne= gotiation should be done on physical connection opening handshake, not when= receiving a multiplex control block.
=A0
--14dae934051de4d60204c5275dc3-- From tyoshino@google.com Wed Jul 18 22:30:53 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BA221F84F1 for ; Wed, 18 Jul 2012 22:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.962 X-Spam-Level: X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH2cNctCEOoV for ; Wed, 18 Jul 2012 22:30:52 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 455A521F84EB for ; Wed, 18 Jul 2012 22:30:52 -0700 (PDT) Received: by yenq13 with SMTP id q13so2625174yen.31 for ; Wed, 18 Jul 2012 22:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=bgaBHCV7Gz+g53hxChjwcqHeuHUsn07cH2gT/7z/k38=; b=l+Od9/djaZy5WS1RPdJwVohaZRHcQPOKKldWc8byfZ8ViACnSNYahVwWHMz4FldFRb xe2v6x+smUswsqlciRNvbnFD8cgKDoD06vqYVmsTz/ZdftGV6QseTTADaqsT5WLtWDPq f1j6IlJG5kRKHaS31qMAuzuDhb5IqWBineKsEJPt/Fm3ciSpz6Sks8eDnKcR013FaFgz nc2eWcyoVfnfCQ1HCdZfttbD4jjrmOKw17b4i0rv4cBBM23AmnstWlcP9DCyQhaBgOdJ EwhlINTDCWIIQI9Ox/qQWG23ojFbh8rEjNiot2WhXuV1RsCMaRNMrE11WvhFu9wp3Vik rBBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=bgaBHCV7Gz+g53hxChjwcqHeuHUsn07cH2gT/7z/k38=; b=Um4HQi2X6zlqC32isivySIYtNLp0DsfFQVafhdDKGc+Yo8ILYi3HBCWksj6tdxkVMg p0WO07AlPlrmmKhhnDTEYsXNcVlW+AhjHNxbrnALfQ9QvYIzkOHK62199So5cmbrNW2N nkFbmyIykwZtoPY4+GWJfP3zqhIW3NEnro9jipy1B8YSmkTc+crRhXcOuvdBcZZnOKOE LcAOKG/yGNvU0x5HSU9wzIlGpwgvpY4f4GEUSXQ1kQZBkDmWEW7m+Wul6HlBj/i4jVqU r65GjfMMPqzIOiQTS9GjwDH+KVxKitkAGT0LnZMmplsYQ15SMNEgx5SMUwlP2Azk53Le Fyug== Received: by 10.50.140.70 with SMTP id re6mr3807704igb.74.1342675904095; Wed, 18 Jul 2012 22:31:44 -0700 (PDT) Received: by 10.50.140.70 with SMTP id re6mr3807694igb.74.1342675903999; Wed, 18 Jul 2012 22:31:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Wed, 18 Jul 2012 22:31:23 -0700 (PDT) In-Reply-To: <00af01cd64bc$ab1c72d0$01555870$@noemax.com> References: <20120704075951.24580.48630.idtracker@ietfa.amsl.com> <50066583.6030902@it.aoyama.ac.jp> <00af01cd64bc$ab1c72d0$01555870$@noemax.com> From: Takeshi Yoshino Date: Thu, 19 Jul 2012 14:31:23 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=e89a8f923b9c4e6d9204c52818e3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnk4j1onjuyN4BbMepU1RLAYXVEi/nT7n3T2z/yt/C/J2qjN5GGkJZFa4ebusf8d2432SLK0tKP/5tk630VwwBhIDRBMWPB1pB37yEPK3HCa4by9DUu9cm6kTeA8m2Qk5qswPShyNhdfqyN3BOHW++6d6gbIXokUIwRXCRbZWq/ekZ5LE0= Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-03.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 05:30:53 -0000 --e89a8f923b9c4e6d9204c52818e3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 18, 2012 at 5:09 PM, Arman Djusupov wrote: > If we would envelope the entire traffic produced by the logical channel > (complete frames including headers) then we would not have this problem, > plus WS mux would be able to multiplex any protocol (e.g. SPDY) and not > only WebSocket frames.**** > > ** > It's hard to sell because of its extra overhead compared to non-muxed. I think we cannot reach consensus by entire traffic enveloping. --e89a8f923b9c4e6d9204c52818e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 18, 2012 = at 5:09 PM, Arman Djusupov <arman@noemax.com> wrote:

If we would enve= lope the entire traffic produced by the logical channel (complete frames in= cluding headers) then we would not have this problem, plus WS mux would be = able to multiplex any protocol (e.g. SPDY) and not only WebSocket frames.

It's hard to sell because o= f its extra overhead compared to non-muxed. I think we cannot reach consens= us by entire traffic enveloping.

--e89a8f923b9c4e6d9204c52818e3-- From Gabriel.Montenegro@microsoft.com Fri Jul 20 12:17:27 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C82421F8564 for ; Fri, 20 Jul 2012 12:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=-2.814, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPpfJqRm9RlV for ; Fri, 20 Jul 2012 12:17:26 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id E3C3A21F855F for ; Fri, 20 Jul 2012 12:17:25 -0700 (PDT) Received: from mail62-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Jul 2012 19:18:21 +0000 Received: from mail62-va3 (localhost [127.0.0.1]) by mail62-va3-R.bigfish.com (Postfix) with ESMTP id 9B4632033F for ; Fri, 20 Jul 2012 19:18:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zzc85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail62-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Gabriel.Montenegro@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail62-va3 (localhost.localdomain [127.0.0.1]) by mail62-va3 (MessageSwitch) id 1342811899627330_18359; Fri, 20 Jul 2012 19:18:19 +0000 (UTC) Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.242]) by mail62-va3.bigfish.com (Postfix) with ESMTP id 8C0191200B9 for ; Fri, 20 Jul 2012 19:18:19 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Jul 2012 19:18:18 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.298.5; Fri, 20 Jul 2012 19:18:16 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.309.3; Fri, 20 Jul 2012 12:18:15 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Fri, 20 Jul 2012 12:18:15 -0700 From: Gabriel Montenegro To: "hybi@ietf.org" Thread-Topic: tentative agenda for Vancouver published Thread-Index: Ac1mrEtfkfkXbi0cTuufaKEdtUgrUQ== Date: Fri, 20 Jul 2012 19:18:15 +0000 Message-ID: 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: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480B5A20TK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [hybi] tentative agenda for Vancouver published X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 19:17:27 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480B5A20TK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Available here: http://tools.ietf.org/wg/hybi/agenda?item=3Dagenda-84-hybi.html --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480B5A20TK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Available here:<= /p>

http://tools.ietf.org/wg/hybi/age= nda?item=3Dagenda-84-hybi.html

 

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480B5A20TK5EX14MBXW604w_-- From tyoshino@google.com Mon Jul 23 01:13:23 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB9921F869A for ; Mon, 23 Jul 2012 01:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.962 X-Spam-Level: X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPAQeUIFldFs for ; Mon, 23 Jul 2012 01:13:20 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3734921F8687 for ; Mon, 23 Jul 2012 01:13:20 -0700 (PDT) Received: by ggnc4 with SMTP id c4so5664861ggn.31 for ; Mon, 23 Jul 2012 01:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=R6Lj7QK1gwta7NZJmn/84TcCFH7smr6FxaiaE/7gl6o=; b=Tybal7mpAfIkJTSM63rachdfODwhihDtxxzj5xQ6sllTI7H8uOdkBPWGplnYbUcEnB WSB8NPXO+z4yl5G2gJXHyEXbeuwftBUoor7bS00I4+t+wJcNaY0+eUXsCVcLThyvH2Dg OUR4UuRMAJ6Al10NhnYrKCTJSd6L0tmTP7jThP9dXalNwfX5P8USPyThnqZx0S4SyI1P 9xWZtKNRQbcSOISwhkfuNDbghNbEJSFHkjffLoWn0JqcZDtEGnlFE6mRZBZ/BHNA7uK6 S5uZquV5cVgCF+BJZL+m612fvA3Fqz9wAyuHqnIa5l7rquIxAEMGla6RChKoyaGCQiFu +z0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=R6Lj7QK1gwta7NZJmn/84TcCFH7smr6FxaiaE/7gl6o=; b=e2JtGDC/JRFThbHWQ64tBWMkuB2grMdF5AubYCih+qc0Zod6/oNID8klo+v1R4lMxm s3e9sStkh1x1JlXfuHWMFflZveSOPq3lWfzfEHAFlEKh5GTswO70JVnA8LJYp6IvbGgH x+fU1oNlkTNGy0gvG2e4GRdpUlessGxl4JhbeMnRuKLecqcmokufdQrihXfyUbL29b6c VddK+81WyOyEAkFj0pZ4EwiXArRJGtdbkSLzsHHdesMhp4KOjGox73UpTDQRacFP2UbE f0HMeWwRoJhWo9pTRmpKXUaBzzlRxoqqxu4PYWYoWBiA1TR0FJQk1CR3FHlT0aEO6WhC wEOA== Received: by 10.50.178.33 with SMTP id cv1mr6629836igc.1.1343031199187; Mon, 23 Jul 2012 01:13:19 -0700 (PDT) Received: by 10.50.178.33 with SMTP id cv1mr6629830igc.1.1343031199098; Mon, 23 Jul 2012 01:13:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Mon, 23 Jul 2012 01:12:58 -0700 (PDT) From: Takeshi Yoshino Date: Mon, 23 Jul 2012 17:12:58 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=e89a8f3bad138b65d804c57ad144 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn7T75BiufUBVdo2LCTkhQ4A8u0oelj9/Okf8E29ULs2kToJHa8ngXMpwy448UG0L9FUaXV8mqTYACZ+T6ak83HvHi8kKN5Zx93ocuyiDF7LLvM0tZit5PmXPLgXdBiw+uVveb3bNu0GeHxV4gdi9ksv5FFC4rkzC+dOL5PiMZp4ZD3e3Q= Subject: [hybi] Status/TODO of multiplex and compression feature X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 08:13:23 -0000 --e89a8f3bad138b65d804c57ad144 Content-Type: text/plain; charset=ISO-8859-1 The topics I'll present in the f2f meeting next week will be almost the same as this mail. * Major changes since the last f2f meeting * Multiplexing - adopted cheap encapsulation -- http://www.ietf.org/mail-archive/web/hybi/current/msg09730.html - added channel slot mechanism to throttle AddChannelRequest and to allow for pre-AddChannelResponse send quota - use the last AddChannel.* as diff base of delta-encoding Compression - decoupled algorithm and common part - echo back algorithm parameters - uploaded per-message version to address multiplexing-compress coordination issue -- mux-friendly per-message version spec http://www.ietf.org/mail-archive/web/hybi/current/msg09758.html * TODOs in editor's mind * Multiplexing - add 1 byte per message penalty to quota -- http://www.ietf.org/mail-archive/web/hybi/current/msg09769.html - spend quota for control frames on logical channel (similar reason) - provide a way to tell the client to fall back to another physical connection (lameduck) -- by using NewChannelSlot or DropChannel - define multiplex error codes - add a section to list defined extension parameters and introduce parameter examples - make diff-base well-defined. AddChannelResponse can be sent out out of order Compression - standardize per-message version instead of per-frame version * Proposed changes to be discussed * Multiplexing - reserve odd or even channel ID for server-initiated channel -- http://www.ietf.org/mail-archive/web/hybi/current/msg09773.html --e89a8f3bad138b65d804c57ad144 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The topics I'll present in the f2f meeting next week will be almos= t the same as this mail.



=
* Major changes since the last f2f meeting *

Multiplexing
- adopted cheap encapsulation
- added channel slot mechanism to throttle AddChannelRequest and to allow f= or=A0pre-AddChannelResponse send quota
- use the last Ad= dChannel.* as diff base of delta-encoding

Compression
- decoupled algorithm and common part
- ech= o back algorithm parameters
- uploaded per-message version to add= ress multiplexing-compress coordination issue
--=A0mux-friendly= =A0per-message version spec=A0http://www.ietf.org/mail-archive/web/hybi/cu= rrent/msg09758.html



* TODOs in editor's m= ind *

Multiplexing
- add 1 byte per = message penalty to quota
- spend quota for control frames on logical channel (similar reason)
- provide a way to=A0tell the client to fall back to another physi= cal connection (lameduck)
-- by using NewChannelSlot or DropChann= el
- define multiplex error codes
- add a section to list defin= ed extension parameters and introduce parameter examples
- make d= iff-base well-defined. AddChannelResponse can be sent out out of order

Compression
- standardize per-message version= instead of per-frame version



* Proposed changes to be discussed *

Multiplexing
- reserve odd or even channel ID for server= -initiated channel

--e89a8f3bad138b65d804c57ad144-- From tyoshino@google.com Wed Jul 25 00:34:07 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFA021F84A1 for ; Wed, 25 Jul 2012 00:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4Ir9l7m4F+9 for ; Wed, 25 Jul 2012 00:34:06 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id F071221F84B3 for ; Wed, 25 Jul 2012 00:34:05 -0700 (PDT) Received: by ggnc4 with SMTP id c4so420364ggn.31 for ; Wed, 25 Jul 2012 00:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=hLg8MuU7tc/VHeRiAgAdyDYVUS3TsxRyhEPt7//E6GU=; b=pAj4xGyM2xK3H9DFyy2d4wrajLCBN5ZdNqwtIOcMGyXRURLgESH/tkzI40wcp7FmHs l33yqzuyk7wLJMbYMvNHQ6CetzCbkkjSAFzvVXus+c90qBwXB86YujKjMuRZm/JOiopq XwZmpdVH3iOnabNC01SuqudUdGlyrVRZ9cwZmu0YJFu1BZNIKToAo3qmix45ezWa/wde 3CKOLWhO51XDKkhXbU4xG4S3nc2tx2g87O3Y1tjzwLqP1oz3owM/nkAcJHjIBZgXfd0B RVB6ZaxtNAY5uaL6PK89pYmwe8VjTZypShECe5uMSscw4UXE7SPAkR+ATTyZOB55dL+E C+yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=hLg8MuU7tc/VHeRiAgAdyDYVUS3TsxRyhEPt7//E6GU=; b=IZkUb1lFQhDIZlhysqhvKML0TYTFCE1+uszcJEelw69DpayCv/92z5fwGQO9xtIXzZ odEj/2KFAUa1ECKm8gUatdbIWVn959HGbx99nSJK+dGYsPBCU7oA2Neeeh5mSgCryNC9 S77bPMgkqGvYtehjBiL8qdzBA+Ct+sH88n2Td7+DONaW4MxIhnm4f8IUArI7a4axskOJ FcojAZtCbBuZAWyeTJh/GFGsmzvlxibnsefRp11yKHW87W96aGBv0Ae+YbjRvxcb5BJd lwsJ3cscaRsHeURwz5SttTVqLzZEYNc9UUbTl0ZrVdzXUaGNd1DQb7fUV9mlO6yQaWDI cOhQ== Received: by 10.42.10.73 with SMTP id p9mr22225934icp.43.1343201644594; Wed, 25 Jul 2012 00:34:04 -0700 (PDT) Received: by 10.42.10.73 with SMTP id p9mr22225922icp.43.1343201644496; Wed, 25 Jul 2012 00:34:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Wed, 25 Jul 2012 00:33:44 -0700 (PDT) From: Takeshi Yoshino Date: Wed, 25 Jul 2012 16:33:44 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=20cf30244ca3e1c8dd04c5a28090 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkGl/Y3+2OCDERbbY9zilQ0ob3e7oxhYzC2um6CsRz2rlZ/xS6iBNT20Jhq+qi0JxL4XV1bdD8ONyzI5Z9oPfaH6iec8YGdNaGLS5PyQv7wDem2pUMB7+wwY6kMlaMpYWvq6fHA6YEEStmDTdWAwi1XFUjf2bMhhnwA2FbXwA3qArnHkXo= Subject: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 07:34:07 -0000 --20cf30244ca3e1c8dd04c5a28090 Content-Type: text/plain; charset=ISO-8859-1 Thanks the authors for preparing this slide http://tools.ietf.org/agenda/84/slides/slides-84-hybi-0.pdf for the next f2f meeting. As one of WebSocket multiplexing spec editors, I'd like to present my thoughts about some of the issues supposing that we evolve WebSocket multiplexing to resolve them and use it to realize HTTP/2.0 multiplexing. * Efficiency of header data transfer - Add SPDY style encoding to AddChannelRequest/Response's Enc type as defined in http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2.6.10 . This makes WebSocket multiplexing as efficient as SPDY to convey HTTP traffic. * Multiplexing with normal WebSocket channels - Add a protocol type property to AddChannelRequest (as a new field or a new handshake header) * Masking - We've defined MASK bit. Maybe we can just relax the restriction of WebSocket/1.0 when the physical connection is negotiated as one for HTTP/2.0 (same origin). But the problem is that there would be transparent "WebSocket" intermediaries that don't allow unmasked frames. * Server initiated stream - Adopt odd/even ID separation as Scott suggested -- e.g. "Sec-WebSocket-Extensions: mux; server-initiated; http20". "server-initiated" introduces the rule, and "http20" depends on that. - Use NewChannelSlot and AddChannelRequest/Response in reverse direction * Flow control - The difference is small among proposals. John designed one for WebSocket multiplexing based on SPDY's one and me also now following the discussion made on spdy-dev as Greg suggested. I'm picking up good points, adjusting them for our purpose and defining commands/fields. I like the new channel slot based throttling idea that is not from SPDY. * Latency - The latest multiplexing allows for pre-handshake data and simultaneous issue of AddChannelRequests except for the physical connection setup time. If NPN is used like SPDY instead of Upgrade, even physical connection may allow for them since there's no risk of cross protocol attack. So, WebSocket multiplexing based HTTP/2.0 doesn't add extra RTT compared to SPDY. * Priority - Add a priority property to AddChannelRequest (as a new field or a new handshake header) * Encoding of channel/stream numbers - Personally, I think we can use one encoding for channel ID and size encoding in multiplex control block Takeshi --20cf30244ca3e1c8dd04c5a28090 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks the authors for preparing this slide=A0http://tools.ietf.org/agend= a/84/slides/slides-84-hybi-0.pdf=A0for the next f2f meeting.
=
As one of WebSocket multiplexing spec editors, I'd like to p= resent my thoughts about some of the issues supposing that we evolve WebSoc= ket multiplexing to resolve them and use it to realize HTTP/2.0 multiplexin= g.

* Efficiency of header data transfer
- Add=A0SPDY style encoding to AddChannelRequest/Response's=A0Enc= type as defined in=A0http://tools.ietf.org/html/draft-mbelshe-htt= pbis-spdy-00#section-2.6.10=A0.=A0This makes WebSocket multiplexing as = efficient as SPDY to convey HTTP traffic.

* Multiplexing with normal WebSocket c= hannels
- Add a protocol type property to AddChannelRequest (as a= new field or a new handshake header)

* = Masking
- We've defined MASK bit. Maybe we can just relax the restriction = of WebSocket/1.0 when the physical connection is negotiated as one for HTTP= /2.0 (same origin). But the problem is that there would be transparent &quo= t;WebSocket" intermediaries that don't allow unmasked frames.

* Server initiated stream
- Adopt od= d/even ID separation as Scott suggested
-- e.g. "Sec-WebSock= et-Extensions: mux; server-initiated; http20". "server-initiated&= quot; introduces the rule, and "http20" depends on that.
- Use NewChannelSlot and AddChannelRequest/Response in reverse directi= on

* Flow control
- The differ= ence is small among proposals. John designed one for WebSocket multiplexing= based on SPDY's one and me also now following the discussion made on s= pdy-dev as Greg suggested. I'm picking up good points, adjusting them f= or our purpose and defining commands/fields. I like the new channel slot ba= sed throttling idea that is not from SPDY.

* Latency
- The latest multiplexing = allows for pre-handshake data and simultaneous issue of AddChannelRequests = except for the physical connection setup time. If NPN is used like SPDY ins= tead of Upgrade, even physical connection may allow for them since there= 9;s no risk of cross protocol attack. So, WebSocket multiplexing based HTTP= /2.0 doesn't add extra RTT compared to SPDY.

* Priority
- Add a priority = property to AddChannelRequest (as a new field or a new handshake header)
* Encoding of channel/stream numbers
- Personally, I think we can use one encoding for channel ID and size encod= ing in multiplex control block

Takeshi<= /div> --20cf30244ca3e1c8dd04c5a28090-- From w@1wt.eu Wed Jul 25 00:54:05 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B28321F852C for ; Wed, 25 Jul 2012 00:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.726 X-Spam-Level: X-Spam-Status: No, score=-5.726 tagged_above=-999 required=5 tests=[AWL=-3.683, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JD4Gg3jNBFHz for ; Wed, 25 Jul 2012 00:54:04 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 5512D21F84F6 for ; Wed, 25 Jul 2012 00:54:04 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q6P7rv2G013800; Wed, 25 Jul 2012 09:53:57 +0200 Date: Wed, 25 Jul 2012 09:53:57 +0200 From: Willy Tarreau To: Takeshi Yoshino Message-ID: <20120725075357.GE12020@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] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 07:54:05 -0000 Hi Takeshi, I have a few comments on your points below. On Wed, Jul 25, 2012 at 04:33:44PM +0900, Takeshi Yoshino wrote: > * Masking > - We've defined MASK bit. Maybe we can just relax the restriction of > WebSocket/1.0 when the physical connection is negotiated as one for > HTTP/2.0 (same origin). But the problem is that there would be transparent > "WebSocket" intermediaries that don't allow unmasked frames. These intermediaries are not an issue right now since the HTTP/2 intermediaries don't exist yet. It will however probably be needed for HTTP/2 to HTTP/1 gateways to support WS/1 as a client when receiving a WS handshake over HTTP/2 compatible framing, and to add masking when sending frames over HTTP/1. > * Server initiated stream > - Adopt odd/even ID separation as Scott suggested +1 on this one. > -- e.g. "Sec-WebSocket-Extensions: mux; server-initiated; http20". > "server-initiated" introduces the rule, and "http20" depends on that. > - Use NewChannelSlot and AddChannelRequest/Response in reverse direction > > * Flow control > - The difference is small among proposals. John designed one for WebSocket > multiplexing based on SPDY's one and me also now following the discussion > made on spdy-dev as Greg suggested. I'm picking up good points, adjusting > them for our purpose and defining commands/fields. I like the new channel > slot based throttling idea that is not from SPDY. As you are probably aware of it, FC is something very difficult to get right, and I from what I understood from past discussions, the SPDY team is always open to improvement in this area. I think that your experience combined with theirs should be useful for both protocols, as you're dealing with very small frames and they're dealing with larger ones, possibly that there are small differences which need to be compared, and then a common flow control could be built. > * Latency > - The latest multiplexing allows for pre-handshake data and simultaneous > issue of AddChannelRequests except for the physical connection setup time. > If NPN is used like SPDY instead of Upgrade, even physical connection may > allow for them since there's no risk of cross protocol attack. So, > WebSocket multiplexing based HTTP/2.0 doesn't add extra RTT compared to > SPDY. Note that NPN won't allow you to mix HTTP/2 and WS frames in the same connection. I think that it's important to be able to convey both frame types over the same connection, which probably means that they'll need to be typed. Maybe instead of odd/even stream IDs we could use them with (0,1,2,3) mod 4 for (req/resp HTTP, cli/srv WS) ? It saves a type. Regards, Willy From tyoshino@google.com Wed Jul 25 01:49:28 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEB921F84FF for ; Wed, 25 Jul 2012 01:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUpp7-RNIivV for ; Wed, 25 Jul 2012 01:49:28 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E770321F84EB for ; Wed, 25 Jul 2012 01:49:27 -0700 (PDT) Received: by yhq56 with SMTP id 56so496699yhq.31 for ; Wed, 25 Jul 2012 01:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=4V8iYNrJ3G7J76iNUiPJ19eDqlpj6CUoVQN4vaeda2o=; b=ahBk4BZQsBewSPTY2ct8Rtuzbom6LiBX6fDepImVXG69yYD4MBF9tLv565HtNDdm/+ UTDaE9F9GyVqqgCgELMajxwPcowV5whuuBtHWvO/vD/dVOJ0HVdnTGQgyVrTQdim9sL/ 2FUV9olv/JvtUdywXjwVgWPq2tnGKiF3am/u/Ju4inwDiuC/RDxt7HNsgxZDobHOekRV XclQrvjYxGON6K4G6xSZUoBKF7TLEmjSUK2cJDAycxHwUE4zPcFZq6rnfoUA2wvcB39V pYzq2eR812QGfLQ57kMeBCPqi1qj/1CQaQKST7AmG1avtTmAl5t38/ZsfNZ4U7w3tl6i qO7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=4V8iYNrJ3G7J76iNUiPJ19eDqlpj6CUoVQN4vaeda2o=; b=ZtfliUs6jJnjUFHy/f06NqvlOTwdGo5xWrIbQmu15yjvRsLkiByizQ+ulnAox1K3I7 lZSLS5V2ci+1OoukKDA5xAp6x6BpX2wtaL3YR5P+NPtFgVncSKujuaj/PtwC+XcdCrU1 joBphqc533XkcebUXsGiN29jAirYT5Mu7bH2GNf2jbuPTzkFZFaXBRY4x7kXTR+RuIam LM9GK7vVerzUma2pfTb8MBzASdt39a6VjMJRlC3wxv7ddVqncblzukg4jrBOss6/9RZc i4i7K8xDuo9y5xXcWGNUW6cIerZ8u6O3yHKbns9nLY+fHyuZriyP1pt2bnzMWOYk8gxy 0cjg== Received: by 10.42.84.16 with SMTP id j16mr22444918icl.7.1343206167107; Wed, 25 Jul 2012 01:49:27 -0700 (PDT) Received: by 10.42.84.16 with SMTP id j16mr22444906icl.7.1343206166979; Wed, 25 Jul 2012 01:49:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Wed, 25 Jul 2012 01:49:05 -0700 (PDT) In-Reply-To: <20120725075357.GE12020@1wt.eu> References: <20120725075357.GE12020@1wt.eu> From: Takeshi Yoshino Date: Wed, 25 Jul 2012 17:49:05 +0900 Message-ID: To: Willy Tarreau Content-Type: multipart/alternative; boundary=90e6ba614b507163c104c5a38e2a X-System-Of-Record: true X-Gm-Message-State: ALoCoQk5R+ujL/0NA9WozNTh4DaSFzwQ2PQf4G9ULt+BrtzfEej3eijugN21F46nsFYuyHfOHG1iy85AeBfq+NAukJnil8lLjRI7+tmUXL20UF5AEPVMBUF9MlhrE+YPvQtUwdQWcDaAoHaSS4zm3bp8j++3LqPbDMBJP6Bq74qQ1SCgNkzzkjU= Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 08:49:28 -0000 --90e6ba614b507163c104c5a38e2a Content-Type: text/plain; charset=ISO-8859-1 Hi Willy, On Wed, Jul 25, 2012 at 4:53 PM, Willy Tarreau wrote: > On Wed, Jul 25, 2012 at 04:33:44PM +0900, Takeshi Yoshino wrote: > > * Masking > > - We've defined MASK bit. Maybe we can just relax the restriction of > > WebSocket/1.0 when the physical connection is negotiated as one for > > HTTP/2.0 (same origin). But the problem is that there would be > transparent > > "WebSocket" intermediaries that don't allow unmasked frames. > > These intermediaries are not an issue right now since the HTTP/2 > intermediaries don't exist yet. It will however probably be needed > for HTTP/2 to HTTP/1 gateways to support WS/1 as a client when > receiving a WS handshake over HTTP/2 compatible framing, and to add > masking when sending frames over HTTP/1. Agreed. But sorry for lack or words. The concern I intended to show is that there might be a transparent intermediary that understands only WebSocket/1.0 between HTTP/2.0 hosts, and it might terminate the HTTP/2.0 session without masking. > * Latency > > - The latest multiplexing allows for pre-handshake data and simultaneous > > issue of AddChannelRequests except for the physical connection setup > time. > > If NPN is used like SPDY instead of Upgrade, even physical connection may > > allow for them since there's no risk of cross protocol attack. So, > > WebSocket multiplexing based HTTP/2.0 doesn't add extra RTT compared to > > SPDY. > > Note that NPN won't allow you to mix HTTP/2 and WS frames in the same > connection. I think that it's important to be able to convey both frame > types over the same connection, which probably means that they'll need > to be typed. Maybe instead of odd/even stream IDs we could use them with > (0,1,2,3) mod 4 for (req/resp HTTP, cli/srv WS) ? It saves a type. > Yes. My idea was that we differentiate HTTP/2.0 and WS on AddChannelRequest using some type field in it as I suggested in "Multiplexing with normal WebSocket channels" in my first mail. It's fine to use IDs as you said, too. Did you mean "normal HTTP / server-push HTTP" where you wrote "req/resp HTTP" above? --90e6ba614b507163c104c5a38e2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Willy,

On Wed, Jul 25, 2= 012 at 4:53 PM, Willy Tarreau <w@1wt.eu> wrote:
On Wed, Jul 25, 2012 at 04= :33:44PM +0900, Takeshi Yoshino wrote:
> * Masking
> - We've defined MASK bit. Maybe we can just relax the restriction = of
> WebSocket/1.0 when the physical connection is negotiated as one for > HTTP/2.0 (same origin). But the problem is that there would be transpa= rent
> "WebSocket" intermediaries that don't allow unmasked fra= mes.

These intermediaries are not an issue right now since the HTTP/2
intermediaries don't exist yet. It will however probably be needed
for HTTP/2 to HTTP/1 gateways to support WS/1 as a client when
receiving a WS handshake over HTTP/2 compatible framing, and to add
masking when sending frames over HTTP/1.

Ag= reed.

But sorry for lack or words. The concern I i= ntended to show is that there might be a transparent intermediary that unde= rstands only=A0WebSocket/1.0 between HTTP/2.0 hosts, and it might terminate= the HTTP/2.0 session without masking.

> * Late= ncy
> - The latest multiplexing allows for pre-handshake data and simultaneo= us
> issue of AddChannelRequests except for the physical connection setup t= ime.
> If NPN is used like SPDY instead of Upgrade, even physical connection = may
> allow for them since there's no risk of cross protocol attack. So,=
> WebSocket multiplexing based HTTP/2.0 doesn't add extra RTT compar= ed to
> SPDY.

Note that NPN won't allow you to mix HTTP/2 and WS frames in the = same
connection. I think that it's important to be able to convey both frame=
types over the same connection, which probably means that they'll need<= br> to be typed. Maybe instead of odd/even stream IDs we could use them with (0,1,2,3) mod 4 for (req/resp HTTP, cli/srv WS) ? It saves a type.

Yes. My idea was that we differentiate HTTP/2.0= and WS on=A0AddChannelRequest=A0using some type field in it=A0as I suggest= ed in=A0"M= ultiplexing with normal WebSocket channels" in my first mail.= =A0It's fine to use IDs as you said, too.

Did you mean "normal HTTP / server-push HTTP"= where you wrote "req/resp HTTP" above?

--90e6ba614b507163c104c5a38e2a-- From w@1wt.eu Wed Jul 25 02:10:07 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3130621F8562 for ; Wed, 25 Jul 2012 02:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.671 X-Spam-Level: X-Spam-Status: No, score=-5.671 tagged_above=-999 required=5 tests=[AWL=-3.628, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hliD-cfXEDxL for ; Wed, 25 Jul 2012 02:10:06 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 52CCB21F855A for ; Wed, 25 Jul 2012 02:10:05 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q6P9A35a014182; Wed, 25 Jul 2012 11:10:03 +0200 Date: Wed, 25 Jul 2012 11:10:03 +0200 From: Willy Tarreau To: Takeshi Yoshino Message-ID: <20120725091003.GA14158@1wt.eu> References: <20120725075357.GE12020@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@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 09:10:07 -0000 On Wed, Jul 25, 2012 at 05:49:05PM +0900, Takeshi Yoshino wrote: > But sorry for lack or words. The concern I intended to show is that there > might be a transparent intermediary that understands only WebSocket/1.0 > between HTTP/2.0 hosts, and it might terminate the HTTP/2.0 session without > masking. Until HTTP/2 is defined, we cannot have such intermediaries intercept HTTP/2 and extract WS information from there, because they simply won't know what HTTP/2 is nor how to decode that stream. So in fact that's why we need to define a correct framing for both, once and for all, before engaging in work on intermediaries (let's void the mess we experienced here with pre-75 and post-75 framings). > > Note that NPN won't allow you to mix HTTP/2 and WS frames in the same > > connection. I think that it's important to be able to convey both frame > > types over the same connection, which probably means that they'll need > > to be typed. Maybe instead of odd/even stream IDs we could use them with > > (0,1,2,3) mod 4 for (req/resp HTTP, cli/srv WS) ? It saves a type. > > > > Yes. My idea was that we differentiate HTTP/2.0 and WS > on AddChannelRequest using some type field in it as I suggested in > "Multiplexing > with normal WebSocket channels" in my first mail. It's fine to use IDs as > you said, too. OK. > Did you mean "normal HTTP / server-push HTTP" where you wrote "req/resp > HTTP" above? Yes, sorry for the confusing name, you're right. I've been used for ages to the req/resp model so it's hard to get it out of my head, and even when I do so, my fingers are still trained to type this :-) Best regards, Willy From arman@noemax.com Wed Jul 25 02:33:57 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CD121F85B6 for ; Wed, 25 Jul 2012 02:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtBHGGm5UNGo for ; Wed, 25 Jul 2012 02:33:56 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8911D21F855A for ; Wed, 25 Jul 2012 02:33:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1343208828; x=1343813628; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=KOPGNB7b2feYu0CkSclGnfZprvk=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=R1PKiLYXpsRt3eBIhnIFPesMw+lM2FzFxTkrxXsUwZ3lBZ9DApFpR63jwa5TQgaangD9eYrJWQ0Eht5hwRB556LBewYONInhqideQ5NVoEUK30N+BfGIW5AhzmqFYG3UrjGD+JFP7rdyRJyHpobOjJWj/eWZoDcTmRQ0WGv1MrI= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id JQG75047; Wed, 25 Jul 2012 12:33:47 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" , "'Willy Tarreau'" References: <20120725075357.GE12020@1wt.eu> In-Reply-To: Date: Wed, 25 Jul 2012 12:33:18 +0300 Message-ID: <001b01cd6a48$8a54b850$9efe28f0$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01CD6A61.AFA1F050" X-Mailer: Microsoft Outlook 14.0 thread-index: AQF4QXzHQX3/ai5UKZHZE8FhMDtxqwJflXYKAarqPISXw7lLEA== Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 09:33:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001C_01CD6A61.AFA1F050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If HTTP/2 is a subprotocol of WS then why not use the WebSocket-Protocol header field that is already there exactly for such cases? With best regards, Arman From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino Sent: Wednesday, July 25, 2012 11:49 AM To: Willy Tarreau Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing Yes. My idea was that we differentiate HTTP/2.0 and WS on AddChannelRequest using some type field in it as I suggested in "Multiplexing with normal WebSocket channels" in my first mail. It's fine to use IDs as you said, too. Did you mean "normal HTTP / server-push HTTP" where you wrote "req/resp HTTP" above? ------=_NextPart_000_001C_01CD6A61.AFA1F050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If HTTP/2 is a subprotocol of WS then why not use the = WebSocket-Protocol header field that is already there exactly for such = cases?

 

With best regards,

Arman

 

 

From:= = hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = Takeshi Yoshino
Sent: Wednesday, July 25, 2012 11:49 = AM
To: Willy Tarreau
Cc: = hybi@ietf.org
Subject: Re: [hybi] HTTP/2.0 framing and = WebSocket multiplexing

 

Yes. My idea was that we differentiate HTTP/2.0 and WS = on AddChannelRequest using some type field in it as I = suggested in "Multiplexing = with normal WebSocket channels" in my first mail. It's = fine to use IDs as you said, too.

 

Did you mean "normal HTTP / server-push = HTTP" where you wrote "req/resp HTTP" = above?

 

------=_NextPart_000_001C_01CD6A61.AFA1F050-- From tyoshino@google.com Wed Jul 25 02:48:52 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEAC21F8599 for ; Wed, 25 Jul 2012 02:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxYiJalvNIF4 for ; Wed, 25 Jul 2012 02:48:51 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83B2021F857D for ; Wed, 25 Jul 2012 02:48:51 -0700 (PDT) Received: by ghbg16 with SMTP id g16so554237ghb.31 for ; Wed, 25 Jul 2012 02:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=xwHqvTLGMCmnVRrJ/VTykG5ugjSFnIeGPoR94+I75po=; b=nF4ndDOJYbuCzjrHhVCdAlg1rqejSSuLoVtRI2VpwL/in1V2eFIV6/x7RIz15p1hq2 nLp8rJQm1PYGJj9ymwCUMBi4QpcBvj2m8ZrSHTeBk063VwtR/Mq5s6Z4yle78sd1Y5Gf V8deVK3AZ92Cfkih302xo/r6TAJun9Z4SEps9jyD0BoB7hj+CgGW0BC69PImyPmD7jS7 ZYHmYe66J3s+kQ69jVv2taU76p7aTP16O5DfffvESovl4XX/gZYosim4dUYzTQQ2YA8e 9v8rCMEEC+N9z4g+AmWFRkOj9SMcv/iOnioW3V201kACpFYeswQufskwmA79GX0Y/eDR yQ+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=xwHqvTLGMCmnVRrJ/VTykG5ugjSFnIeGPoR94+I75po=; b=HGxYsk1WF9K4q1TIhr4TpwRXMrdVhY5GRgJ8Cb7Wu0/EV0BTPDamffowKA/8oRqlJJ Dphfs2DhNzcjlYgGHmLaV7DzoqvpWhJDc7LGEkBq4+lVpyeJSiFIdQc1EKLyd2iwKZmE PJozPmDY8xVftGetLL72Eac27KVtD1fhF3hZMewhevPTfVPGhKhMy9GmjwRGrOpcvJH6 LCJIfDRhqPl2uYfIi+Pw+edjclpV6+iVvqyF5KnINw2lp5YZbbWOmsM4HFEcfIbWWM+e lQF/gW9t1i0r+dX27bMITQwPyyNMoq9akf3dB/bCEsAlhDQI7wbTBtrdgZvo61G2bCRg uHBA== Received: by 10.42.10.73 with SMTP id p9mr23098008icp.43.1343209730480; Wed, 25 Jul 2012 02:48:50 -0700 (PDT) Received: by 10.42.10.73 with SMTP id p9mr23097991icp.43.1343209730356; Wed, 25 Jul 2012 02:48:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Wed, 25 Jul 2012 02:48:29 -0700 (PDT) In-Reply-To: <001b01cd6a48$8a54b850$9efe28f0$@noemax.com> References: <20120725075357.GE12020@1wt.eu> <001b01cd6a48$8a54b850$9efe28f0$@noemax.com> From: Takeshi Yoshino Date: Wed, 25 Jul 2012 18:48:29 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=20cf30244ca3d635bd04c5a4625f X-System-Of-Record: true X-Gm-Message-State: ALoCoQnm2/2I16vshQurVHKKbkPJOwjjNMURkXUimkrs9MvrV/VRZLvZJgRpwl7tSE6Wqdq7g3HUfqN+sDNlUXIf33K/LCKpHUp7R0+dibdBEQxUMcnX65eMV1p77UaEBqjD0WNah5/L2bZ795h0uEYXOG+D90Mhp35gEqkVz20KonY6QWIjLz0= Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 09:48:52 -0000 --20cf30244ca3d635bd04c5a4625f Content-Type: text/plain; charset=ISO-8859-1 Subprotocol is under control of scripts on browsers. It allows scripts to send an arbitrary HTTP request. There might be some security risk. It's ok if subprotocol is also exchanged, but for this case, help by extension mechanism is necessary by which server can confirm that the requests are controlled not by any script but by the user-agent. On Wed, Jul 25, 2012 at 6:33 PM, Arman Djusupov wrote: > If HTTP/2 is a subprotocol of WS then why not use the WebSocket-Protocol > header field that is already there exactly for such cases?**** > > ** ** > > With best regards,**** > > Arman**** > > ** ** > > ** ** > > *From:* hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] *On Behalf > Of *Takeshi Yoshino > *Sent:* Wednesday, July 25, 2012 11:49 AM > *To:* Willy Tarreau > *Cc:* hybi@ietf.org > *Subject:* Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing**** > > ** ** > > Yes. My idea was that we differentiate HTTP/2.0 and WS > on AddChannelRequest using some type field in it as I suggested in "Multiplexing > with normal WebSocket channels" in my first mail. It's fine to use IDs as > you said, too. > --20cf30244ca3d635bd04c5a4625f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Subprotocol is under = control of scripts on browsers. It allows scripts to send an arbitrary HTTP= request. There might be some security risk.

It's ok if subprotocol is also exchang= ed, but for this case, help by extension mechanism is necessary by which se= rver can confirm that the requests are controlled not by any script but by = the user-agent.

On Wed, Jul= 25, 2012 at 6:33 PM, Arman Djusupov <arman@noemax.com> wrote= :

If HTTP/2 is a subprotocol of WS then why no= t use the WebSocket-Protocol header field that is already there exactly for= such cases?

=A0<= /p>

With best regards,<= /u>

Arman

=A0

=A0<= /p>

From: hybi-bounces@ietf.org= [mailto:hyb= i-bounces@ietf.org] On Behalf Of Takeshi Yoshino
Sent: Wednesday, July 25, 2012 11:49 AM
To: Willy Tarreau<= br>Cc: hybi@ietf.= org
Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multip= lexing

=A0

Yes. My idea was that we differentiate = HTTP/2.0 and WS on=A0AddChannelRequest=A0using some type field in it=A0as I= suggested in=A0"Multiplexing with normal WebSocket channel= s" in my first mail.=A0It's fine to use IDs as you said, to= o.


--20cf30244ca3d635bd04c5a4625f-- From arman@noemax.com Wed Jul 25 03:05:11 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B253E21F84E6 for ; Wed, 25 Jul 2012 03:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ensGYWuUbs1w for ; Wed, 25 Jul 2012 03:05:09 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD8621F84CD for ; Wed, 25 Jul 2012 03:05:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1343210701; x=1343815501; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=R/IA/LhF0rtIJdAT9Zlom9s04PI=; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:In-Reply-To:References; b=MOWFl6Ndh9uVXyBUzkVJ3/SW71Oox3dXKj7TMe9I4fKmD3n9+AskixmmNFNx8IF4D5rGNOPOf4HRY41vItjU36awYN27b+LxRt0cW1fd9/00tIgMh7EjXolmChHxKHqKPHA84iCtLkJMpphXHDoSXqnrwXzpWCA3/st4Vm1hPsk= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id JRD32859; Wed, 25 Jul 2012 13:04:59 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" , References: In-Reply-To: Date: Wed, 25 Jul 2012 13:04:29 +0300 Message-ID: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01CD6A66.0B2DECE0" X-Mailer: Microsoft Outlook 14.0 thread-index: AQF4QXzHQX3/ai5UKZHZE8FhMDtxq5fkFe8A Content-Language: en-us Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 10:05:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0032_01CD6A66.0B2DECE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Since HTTP/2 needs mux and flow control it appears to be reasonable to use the WS mux and frame format for HTTP/2, so that HTTP/2 becomes a subprotocol of WS. In this case the HTTP/2 frame can be stripped of unnecessary fields such as the length and channelID. In this scenario NPN becomes unnecessary. Producing an additional mux protocol on top of HTTP/2 or SPDY doesn't seem ideal. IMHO either SPDY/HTTP/2 should use WS frames and mux, or WS should be muxed over SPDY and HTTP/2. From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino Sent: Wednesday, July 25, 2012 10:34 AM To: hybi@ietf.org Subject: [hybi] HTTP/2.0 framing and WebSocket multiplexing * Efficiency of header data transfer - Add SPDY style encoding to AddChannelRequest/Response's Enc type as defined in http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2.6.10 . This makes WebSocket multiplexing as efficient as SPDY to convey HTTP traffic. If you mean compressing the headers using zlib initialized with a predefined dictionary then this would make sense, but we already have integrated per-message compression for WS so this option should be enabled only if WS compression is not used. * Server initiated stream - Adopt odd/even ID separation as Scott suggested -- e.g. "Sec-WebSocket-Extensions: mux; server-initiated; http20". "server-initiated" introduces the rule, and "http20" depends on that. - Use NewChannelSlot and AddChannelRequest/Response in reverse direction This is the right thing to do. * Latency - The latest multiplexing allows for pre-handshake data and simultaneous issue of AddChannelRequests except for the physical connection setup time. If NPN is used like SPDY instead of Upgrade, even physical connection may allow for them since there's no risk of cross protocol attack. So, WebSocket multiplexing based HTTP/2.0 doesn't add extra RTT compared to SPDY. Agree, if NPN is used, both masking and this restriction can be lifted. * Priority - Add a priority property to AddChannelRequest (as a new field or a new handshake header) Possible, but I'm skeptical that implementation would really observe these fields. I don't think any prioritizing is currently being widely used by HTTP servers. Takeshi With best regards, Arman ------=_NextPart_000_0032_01CD6A66.0B2DECE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since HTTP/2 needs mux and flow control it appears to be reasonable = to use the WS mux and frame format for HTTP/2, so that HTTP/2 becomes a = subprotocol of WS. In this case the HTTP/2 frame can be stripped of = unnecessary fields such as the length and channelID. In this scenario = NPN becomes unnecessary.

 

Producing an additional mux protocol on top of HTTP/2 or SPDY doesn't = seem ideal. IMHO either SPDY/HTTP/2 should use WS frames and mux, or WS = should be muxed over SPDY and HTTP/2.

 

From:= = hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.= org] On Behalf Of Takeshi Yoshino
Sent: Wednesday, = July 25, 2012 10:34 AM
To: hybi@ietf.org
Subject: = [hybi] HTTP/2.0 framing and WebSocket = multiplexing

 

* Efficiency = of header data transfer

- = Add SPDY style encoding to AddChannelRequest/Response's Enc = type as defined in http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-= 2.6.10 . This makes WebSocket multiplexing as efficient as = SPDY to convey HTTP traffic.

 

If you mean compressing the  headers using zlib initialized with = a predefined dictionary then this would make sense, but we already have = integrated per-message compression for WS so this option should be = enabled only if WS compression is not used.

 

* Server = initiated stream

- Adopt odd/even ID = separation as Scott suggested

-- e.g. = "Sec-WebSocket-Extensions: mux; server-initiated; http20". = "server-initiated" introduces the rule, and "http20" = depends on that.

- Use NewChannelSlot = and AddChannelRequest/Response in reverse direction

 

This is the right thing to do.

 

* = Latency

- The latest multiplexing = allows for pre-handshake data and simultaneous issue of = AddChannelRequests except for the physical connection setup time. If NPN = is used like SPDY instead of Upgrade, even physical connection may allow = for them since there's no risk of cross protocol attack. So, WebSocket = multiplexing based HTTP/2.0 doesn't add extra RTT compared to = SPDY.

 

Agree, if NPN is used, both masking and this restriction can be = lifted.

 

* = Priority

- Add a priority property to = AddChannelRequest (as a new field or a new handshake = header)

 

Possible, but I’m skeptical that implementation would really = observe these fields. I don’t think any prioritizing is currently = being widely used by HTTP servers.

 

Takeshi

 

With best regards,

Arman

 

------=_NextPart_000_0032_01CD6A66.0B2DECE0-- From w@1wt.eu Wed Jul 25 03:50:09 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF82221F84F2 for ; Wed, 25 Jul 2012 03:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.618 X-Spam-Level: X-Spam-Status: No, score=-5.618 tagged_above=-999 required=5 tests=[AWL=-3.575, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-3DhJ8QbYhN for ; Wed, 25 Jul 2012 03:50:09 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 24E5B21F8475 for ; Wed, 25 Jul 2012 03:50:08 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q6PAo1ah014651; Wed, 25 Jul 2012 12:50:01 +0200 Date: Wed, 25 Jul 2012 12:50:01 +0200 From: Willy Tarreau To: Arman Djusupov Message-ID: <20120725105001.GA14617@1wt.eu> References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 10:50:10 -0000 On Wed, Jul 25, 2012 at 01:04:29PM +0300, Arman Djusupov wrote: > Since HTTP/2 needs mux and flow control it appears to be reasonable to use > the WS mux and frame format for HTTP/2, so that HTTP/2 becomes a subprotocol > of WS. This does not seam reasonable to me. It's hard for me to explain why but it seems a bit reversed. In my opinion we should have a common framing layer offering MUX and bidir-communications on top of which we have HTTP for object retrieval and WS for short interactive exchanges (could be seen as less typed data without headers and without buffering). So you'd have : ---------+-------- HTTP/2 | WS/2 ---------+-------- framing ------------------ transport ------------------ Regards, Willy From tyoshino@google.com Wed Jul 25 04:31:14 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1149721F85B4 for ; Wed, 25 Jul 2012 04:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3ZiNmDaHLSR for ; Wed, 25 Jul 2012 04:31:13 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 59C9021F8599 for ; Wed, 25 Jul 2012 04:31:13 -0700 (PDT) Received: by yhq56 with SMTP id 56so643084yhq.31 for ; Wed, 25 Jul 2012 04:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=BDPynu8co5xFCyAh7ngVyeBSNOUI0D1ndyCnJkTnRnE=; b=AOv6v9roUaGQoixqBwrZ9Tti4Wr3qziUsCiaya+diLa92z4SxAwdiz9n/53+y6BxmY CZA0WFRq4EzH2fAOXwetPU1RuyGolsFH0wYLpW95dtyE1aC+Fx7FbJfaAH6TQnFNFuG6 /gnmqoxr0ttniTeokhoXjcfUY9rdhDGJWZir5mKlcnzRedBv0YUFAfcq7msZ2z+FMWKi acylVxE+a6BthZQmq472UKNZiMaLKH9ZZEPiYu1rAh5MVvVmH+xnA86lDS/ZTUsAlbLe iFXdF+ky3I7ejvJWST3h3uiwj4n8aK3agn9kaItbvVbmDqumoPDZMhIQviS0h/dIAmgR 3DPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=BDPynu8co5xFCyAh7ngVyeBSNOUI0D1ndyCnJkTnRnE=; b=UgzniXtjiYzpJzZ3B0NeFFL0y2CLMeaJ0U+bn5oZQEzO+t+VqD1YgNIqy58i2zXueR azKDBcSJ0w5T9DaK23nnwOFijDMxszM4NbTy5h/gp7BlUOZ+9aN74ajFtY3+Og6EogIh xv4oS6mpYSy1AomFNVbPJUEEDZQQZye6q8dV7cXspB4idOYjxw4WpFv3YPqgFBVoAB2c rvhP0hYmwuTiowvRDrPyJXgswtgYyYeoGHxfOy+p6JfIAdejFLPVC6bfo49rl67nh+DA sVh4+vY5P69CD2TxU+GoT0k7irzDOg9k23dOX56CJNo66BAzHayDfBZ07sGZ9Q6vBqtb BgZw== Received: by 10.42.84.16 with SMTP id j16mr23506737icl.7.1343215872712; Wed, 25 Jul 2012 04:31:12 -0700 (PDT) Received: by 10.42.84.16 with SMTP id j16mr23506722icl.7.1343215872620; Wed, 25 Jul 2012 04:31:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Wed, 25 Jul 2012 04:30:52 -0700 (PDT) In-Reply-To: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> From: Takeshi Yoshino Date: Wed, 25 Jul 2012 20:30:52 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=90e6ba614b50f1b8b304c5a5d030 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlKWG2OyCGcnvwJXzO0O46wEKCl++QygY956sukb8iwqaCc/6SmGu6RRA4iv2hd/8CZBrjjrp9apQBSc44vQ3UrI+UwLZR7ZifMeaTdejI0mHT50LZFPBuGkGHc2MoFmLrzlVBzTM4hKL+hLO0yGioeCzcy3BhY0px9O/EeT3J8CXaTlR4= Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 11:31:14 -0000 --90e6ba614b50f1b8b304c5a5d030 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 25, 2012 at 7:04 PM, Arman Djusupov wrote: > *From:* hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] *On Behalf > Of *Takeshi Yoshino > > *Sent:* Wednesday, July 25, 2012 10:34 AM > *To:* hybi@ietf.org > *Subject:* [hybi] HTTP/2.0 framing and WebSocket multiplexing**** > > ** ** > > * Efficiency of header data transfer**** > > - Add SPDY style encoding to AddChannelRequest/Response's Enc type as > defined in > http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2.6.10 . This > makes WebSocket multiplexing as efficient as SPDY to convey HTTP traffic.* > *** > > ** ** > > If you mean compressing the headers using zlib initialized with a > predefined dictionary then this would make sense, but we already have > integrated per-message compression for WS so this option should be enabled > only if WS compression is not used. > Yes if that combination is efficient enough. --90e6ba614b50f1b8b304c5a5d030 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 25, 2012 = at 7:04 PM, Arman Djusupov <arman@noemax.com> wrote:

<= b>From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = Takeshi Yoshino

Sent: Wednesday, July 25, 201= 2 10:34 AM
To: hybi@ietf.org
Subject: [hybi] HTTP/2.0 framing and WebSocket multiplexing

=A0<= /p>

* Efficiency of header data transfer

- Add=A0SPDY style encoding to AddChannelRequest/Res= ponse's=A0Enc type as defined in=A0http://to= ols.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2.6.10=A0.=A0Th= is makes WebSocket multiplexing as efficient as SPDY to convey HTTP traffic= .

=A0<= /p>

If you mean comp= ressing the =A0headers using zlib initialized with a predefined dictionary = then this would make sense, but we already have integrated per-message comp= ression for WS so this option should be enabled only if WS compression is n= ot used.=A0


Yes if that combination is efficient= enough.

--90e6ba614b50f1b8b304c5a5d030-- From arman@noemax.com Wed Jul 25 04:56:18 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4546021F85CD for ; Wed, 25 Jul 2012 04:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG4v3L1oDyZT for ; Wed, 25 Jul 2012 04:56:16 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 92FAC21F84EF for ; Wed, 25 Jul 2012 04:56:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1343217368; x=1343822168; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=DmFZpt/n5wZ+a5i6UrCz/k06v2I=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=j/C43qPmJ2I5rcbgyuzU/ICENUWgDs2JXYaIztJceU55Y+kQIIe5hjOll4y7+dhtZRlAgg44vHuedEgVEJ2d59xIKBDFx5c5n/VDVudtR497xycum5vtCYIrSiUCgQRIUVnUIqkNk71Vpvl9FSdX5FtHJnPA2xtlRph6EaWUenw= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id JSD26507; Wed, 25 Jul 2012 14:56:07 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" References: <20120725075357.GE12020@1wt.eu> <001b01cd6a48$8a54b850$9efe28f0$@noemax.com> In-Reply-To: Date: Wed, 25 Jul 2012 14:55:37 +0300 Message-ID: <004801cd6a5c$6c4a5a40$44df0ec0$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01CD6A75.919A0340" X-Mailer: Microsoft Outlook 14.0 thread-index: AQF4QXzHQX3/ai5UKZHZE8FhMDtxqwJflXYKAarqPIQB/X+/CQJt65/7l6CFSpA= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 11:56:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0049_01CD6A75.919A0340 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Alternatively browsers could prohibit scripts from using some values in the sub-protocol header, for example the value "http/2", so that the existing protocol negotiation mechanism can be reused. Browsers anyway need to check the values provided by scripts, otherwise scripts can still inject a header into the WS handshake. With best regards, Arman From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Wednesday, July 25, 2012 12:48 PM To: Arman Djusupov Cc: Willy Tarreau; hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing Subprotocol is under control of scripts on browsers. It allows scripts to send an arbitrary HTTP request. There might be some security risk. It's ok if subprotocol is also exchanged, but for this case, help by extension mechanism is necessary by which server can confirm that the requests are controlled not by any script but by the user-agent. On Wed, Jul 25, 2012 at 6:33 PM, Arman Djusupov wrote: If HTTP/2 is a subprotocol of WS then why not use the WebSocket-Protocol header field that is already there exactly for such cases? With best regards, Arman From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino Sent: Wednesday, July 25, 2012 11:49 AM To: Willy Tarreau Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing Yes. My idea was that we differentiate HTTP/2.0 and WS on AddChannelRequest using some type field in it as I suggested in "Multiplexing with normal WebSocket channels" in my first mail. It's fine to use IDs as you said, too. ------=_NextPart_000_0049_01CD6A75.919A0340 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alternatively browsers could prohibit scripts from using some values = in the sub-protocol header, for example the value “http/2”, = so that the existing protocol negotiation mechanism can be = reused.

Browsers anyway need to check the values provided by scripts, = otherwise scripts can still inject a header into the WS = handshake.

 

With best regards,

Arman

 

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Wednesday, = July 25, 2012 12:48 PM
To: Arman Djusupov
Cc: Willy = Tarreau; hybi@ietf.org
Subject: Re: [hybi] HTTP/2.0 framing = and WebSocket multiplexing

 

Subprotocol is under control of scripts on browsers. = It allows scripts to send an arbitrary HTTP request. There might be some = security risk.

 

It's ok if subprotocol is also exchanged, but for this = case, help by extension mechanism is necessary by which server can = confirm that the requests are controlled not by any script but by the = user-agent.

 

On Wed, Jul 25, 2012 at 6:33 PM, Arman Djusupov <arman@noemax.com> = wrote:

If HTTP/2 is a subprotocol of WS then why not use the = WebSocket-Protocol header field that is already there exactly for such = cases?

 

With best regards,

Arman

 

 

From:= = hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi = Yoshino
Sent: Wednesday, July 25, 2012 11:49 AM
To: = Willy Tarreau
Cc: hybi@ietf.org
Subject: Re: [hybi] = HTTP/2.0 framing and WebSocket = multiplexing

 <= /o:p>

Yes. My = idea was that we differentiate HTTP/2.0 and WS = on AddChannelRequest using some type field in it as I = suggested in "Multiplexing = with normal WebSocket channels" in my first mail. It's = fine to use IDs as you said, = too.

 

------=_NextPart_000_0049_01CD6A75.919A0340-- From tyoshino@google.com Wed Jul 25 05:14:27 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4353D21F85DF for ; Wed, 25 Jul 2012 05:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch3SqusEOvte for ; Wed, 25 Jul 2012 05:14:26 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 827EC21F85DA for ; Wed, 25 Jul 2012 05:14:26 -0700 (PDT) Received: by yhq56 with SMTP id 56so690272yhq.31 for ; Wed, 25 Jul 2012 05:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=KXbyQADN7WZQz7Eu1un4rVrXANzleuzm9bfTzpddEi0=; b=d96xO/y9EgoflgDuDLEt6EaDOyV0dfP7s9w5NuMbrL2HiHqsSeQuTUJQiuRy1oB2yE VYnLy9qFGR21/GLPoUEyk0Num+JITx1rmBvQ8qzIAdfLmbqjavT5RxwEDZDBXz+Uil8f b67n3oivYXWBYDT00NfAi+f4fJCJit210k/35X3WEN24PUw/1afh2JkkB7MJV2c1C4rP Dz8IP8b7N9P8fqFJkEXqlM9VJcps3sK+NLVs8Toy8tGCD31w2BuNoQNA3xFV8t+9bRYW ezfl+qF7ftBPXfAXj/wHoB+dBwgVKRU1h4LLTNAh8fohsRuZZaHQ0ABA497RraMDZvM3 c84A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=KXbyQADN7WZQz7Eu1un4rVrXANzleuzm9bfTzpddEi0=; b=Je8EkcCx2RNUvgWLhqQ0Y5sJwRB7bb08pe1wrLUCg1Tpdk0ji2RIPoVOiR/ECq4jrQ vTbjyOAG/wKj7tbsfRHOTDQuw1HMKuFFnGsaMZ3AYCx7HSLBejF3dBk7lljdYjBpc+4y 7AHFHbDkDXnrnd0JPWhbJ3rNnfnaPtQmj5r69PrrO62sgTcmlnHtbZCzjncQdhb5PnLi Bl0X/4S+AYwgJpumHiV6wXxXMphTwhQk/N9k9/vhiYJRUyWP+R+l2rrtBVVD2kcK8Nwv Q6MWr2MiWInNjblKicyS8qOtA6DawgGm79toj6Deet1atj+PkWz9r8n1lhQGR9dQY9Hz TNbw== Received: by 10.42.84.16 with SMTP id j16mr23784920icl.7.1343218465707; Wed, 25 Jul 2012 05:14:25 -0700 (PDT) Received: by 10.42.84.16 with SMTP id j16mr23784893icl.7.1343218465496; Wed, 25 Jul 2012 05:14:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Wed, 25 Jul 2012 05:14:05 -0700 (PDT) In-Reply-To: <20120725105001.GA14617@1wt.eu> References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> <20120725105001.GA14617@1wt.eu> From: Takeshi Yoshino Date: Wed, 25 Jul 2012 21:14:05 +0900 Message-ID: To: Willy Tarreau Content-Type: multipart/alternative; boundary=90e6ba614b507dde0604c5a66bea X-System-Of-Record: true X-Gm-Message-State: ALoCoQn0htMqJn6ZLyENBit7vBp5G+LCsods9nDALj/vrY38+JD+ESD+YNH9EbFHAlqxRjCD9eGczJbEbuD9e3IJOmqdV15i80fewTiYBuZrRdCXKEJerHPJ9X7vCS60y7Evi6CAk0DEI7KThac7ELqEqAmPQM0p7wH5zZDbGxx3cwI3LSK3UqM= Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 12:14:27 -0000 --90e6ba614b507dde0604c5a66bea Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 25, 2012 at 7:50 PM, Willy Tarreau wrote: > On Wed, Jul 25, 2012 at 01:04:29PM +0300, Arman Djusupov wrote: > > Since HTTP/2 needs mux and flow control it appears to be reasonable to > use > > the WS mux and frame format for HTTP/2, so that HTTP/2 becomes a > subprotocol > > of WS. > > This does not seam reasonable to me. It's hard for me to explain why > but it seems a bit reversed. In my opinion we should have a common > framing layer offering MUX and bidir-communications on top of which we > have HTTP for object retrieval and WS for short interactive exchanges > (could be seen as less typed data without headers and without buffering). Forgetting what their original target applications are, SPDY is a versatile multiplexing protocol with flow control - for X key-value pairs + 1 (possibly endless) binary string - simple encoding/field, int32 aligned - more overhead WebSocket multiplexing is one - for X key-value pairs + Y (possibly unlimited number of) (possibly endless) binary strings - complicated encoding/field, not int32 aligned - less overhead I think this is what they are in the context of HTTP/2.0 framing discussion. SPDY lacks message semantics necessary to lay WS semantics. But Takashi has been trying to do it by using SPDY's HEADERS as message boundary signal. It works. (See spdy-dev for detail) --90e6ba614b507dde0604c5a66bea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 25, 2012 = at 7:50 PM, Willy Tarreau <w@1wt.eu> wrote:
On Wed, Jul 25, 2012 at 01:04:29PM +0300, Arman Djusupov = wrote:
> Since HTTP/2 needs mux and flow control it appears to be reasonable to= use
> the WS mux and frame format for HTTP/2, so that HTTP/2 becomes a subpr= otocol
> of WS.

This does not seam reasonable to me. It's hard for me to explain = why
but it seems a bit reversed. In my opinion we should have a common
framing layer offering MUX and bidir-communications on top of which we
have HTTP for object retrieval and WS for short interactive exchanges
(could be seen as less typed data without headers and without buffering).

Forgetting what their original target applic= ations are,

SPDY is a versatile multiplexing proto= col with flow control
- for X key-value pairs + 1 (possibly endless) binary string
- simple encoding/field,=A0int32 aligned
- more overhead

WebSocket multiplexing is one
- for X key-value= pairs + Y=A0(possibly unlimited number of)=A0(possibly endless) binary str= ings
- complicated encoding/field,=A0not int32 aligned
- less ove= rhead

I think this is what they are in the context= of HTTP/2.0 framing discussion.

SPDY lacks messag= e semantics necessary to lay WS semantics. But Takashi has been trying to d= o it by using SPDY's HEADERS as message boundary signal. It works. (See= spdy-dev for detail)
=A0
--90e6ba614b507dde0604c5a66bea-- From w@1wt.eu Wed Jul 25 05:52:34 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A7521F8559 for ; Wed, 25 Jul 2012 05:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.566 X-Spam-Level: X-Spam-Status: No, score=-5.566 tagged_above=-999 required=5 tests=[AWL=-3.523, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VVGj4l8FFer for ; Wed, 25 Jul 2012 05:52:33 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 498AD21F855E for ; Wed, 25 Jul 2012 05:52:28 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q6PCqNiM015285; Wed, 25 Jul 2012 14:52:23 +0200 Date: Wed, 25 Jul 2012 14:52:23 +0200 From: Willy Tarreau To: Takeshi Yoshino Message-ID: <20120725125223.GA15238@1wt.eu> References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> <20120725105001.GA14617@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@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 12:52:34 -0000 On Wed, Jul 25, 2012 at 09:14:05PM +0900, Takeshi Yoshino wrote: > Forgetting what their original target applications are, > > SPDY is a versatile multiplexing protocol with flow control > - for X key-value pairs + 1 (possibly endless) binary string > - simple encoding/field, int32 aligned > - more overhead > > WebSocket multiplexing is one > - for X key-value pairs + Y (possibly unlimited number of) (possibly > endless) binary strings > - complicated encoding/field, not int32 aligned > - less overhead > > I think this is what they are in the context of HTTP/2.0 framing discussion. 100% agree. What I meant was that SPDY is not *only* the framing and WS is not *only* the fraiming either. Both share that huge part, but there are semantics on top of this framing for application level usage, which is why I've been saying for some time that we should make it clear that there is a framing and a framed protocol. One is just about transporting frames, and other ones are used to transfer information with semantics. > SPDY lacks message semantics necessary to lay WS semantics. But Takashi has > been trying to do it by using SPDY's HEADERS as message boundary signal. It > works. (See spdy-dev for detail) Probably that's the point where the split between framing and application layer use would make sense. In short, we would define what a frame should look like, how to open new channels, how to mux channels, how to apply flow control. This is the framing layer. Then on top of that we would describe how HTTP/2 and WS are transported. Regards, Willy From arman@noemax.com Wed Jul 25 06:17:16 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC56621F8540 for ; Wed, 25 Jul 2012 06:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8x3z57ySesJ for ; Wed, 25 Jul 2012 06:17:15 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id CC36B21F852E for ; Wed, 25 Jul 2012 06:17:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1343222226; x=1343827026; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=v1e9JpJFH8nORcBXbJcTlF4trHc=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=MZEr8mWuxKWzb+69N5YW3RJTJiu4OnoxA30z/Mwm/T1M6aIiTZ4scFwM7aoe/gGK54yRBQ5kTTQFyzGaKswDGsWxSjLnLcInbpiCHnz+3uqfRZyJri9M19XtAAN63D6iSEL7cohki8UP9PJssOTpkeTgvN1cE97Jug3REUKipLA= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id JUQ28105; Wed, 25 Jul 2012 16:17:05 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" , "'Willy Tarreau'" References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> <20120725105001.GA14617@1wt.eu> In-Reply-To: Date: Wed, 25 Jul 2012 16:16:35 +0300 Message-ID: <005701cd6a67$bbdcd500$33967f00$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01CD6A80.E12B93A0" X-Mailer: Microsoft Outlook 14.0 thread-index: AQF4QXzHQX3/ai5UKZHZE8FhMDtxqwH/aSG6AnfjcEACu1cbbZeqtqIA Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 13:17:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0058_01CD6A80.E12B93A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't see any practical reasons why not to reuse WS for HTTP/2. WS already looks simply as a subset of HTTP/2, offering only "Mux and bidir-communication" to which HTTP/2 has to add whatever extra is required. The difference between a WS message and an HTTP message is only the presence of the HTTP header, otherwise WS has everything needed to move HTTP requests and responses in any direction. If WS/2 and HTTP/2 would be sharing the same framing layer as mentioned by Willy Tarreau, then this common framing layer will practically be the whole WS/2 because there is nothing extra WS/2 can offer. So during the handshake, instead of either WS/2 or HTTP/2, it would be more like "raw WS/2 or WS/2 + HTTP/2". With best regards, Arman From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Wednesday, July 25, 2012 3:14 PM To: Willy Tarreau Cc: Arman Djusupov; hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing On Wed, Jul 25, 2012 at 7:50 PM, Willy Tarreau wrote: On Wed, Jul 25, 2012 at 01:04:29PM +0300, Arman Djusupov wrote: > Since HTTP/2 needs mux and flow control it appears to be reasonable to use > the WS mux and frame format for HTTP/2, so that HTTP/2 becomes a subprotocol > of WS. This does not seam reasonable to me. It's hard for me to explain why but it seems a bit reversed. In my opinion we should have a common framing layer offering MUX and bidir-communications on top of which we have HTTP for object retrieval and WS for short interactive exchanges (could be seen as less typed data without headers and without buffering). Forgetting what their original target applications are, SPDY is a versatile multiplexing protocol with flow control - for X key-value pairs + 1 (possibly endless) binary string - simple encoding/field, int32 aligned - more overhead WebSocket multiplexing is one - for X key-value pairs + Y (possibly unlimited number of) (possibly endless) binary strings - complicated encoding/field, not int32 aligned - less overhead I think this is what they are in the context of HTTP/2.0 framing discussion. SPDY lacks message semantics necessary to lay WS semantics. But Takashi has been trying to do it by using SPDY's HEADERS as message boundary signal. It works. (See spdy-dev for detail) ------=_NextPart_000_0058_01CD6A80.E12B93A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t see any practical reasons why not to reuse WS for = HTTP/2. WS already looks simply as a subset of HTTP/2, offering only = “Mux and bidir-communication” to which HTTP/2 has to add = whatever extra is required.

 

The difference between a WS message and an HTTP message is only the = presence of the HTTP header, otherwise WS has everything needed to move = HTTP requests and responses in any direction. If WS/2 and HTTP/2 would = be sharing the same framing layer as mentioned by Willy Tarreau, then = this common framing layer will practically be the whole WS/2 because = there is nothing extra WS/2 can offer.

 

So during the handshake, instead of either WS/2 or HTTP/2, it would = be more like “raw WS/2 or WS/2 + = HTTP/2”.

 

With best regards,

Arman

 

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Wednesday, = July 25, 2012 3:14 PM
To: Willy Tarreau
Cc: Arman = Djusupov; hybi@ietf.org
Subject: Re: [hybi] HTTP/2.0 framing = and WebSocket multiplexing

 

On = Wed, Jul 25, 2012 at 7:50 PM, Willy Tarreau <w@1wt.eu> = wrote:

On Wed, Jul 25, 2012 at 01:04:29PM +0300, = Arman Djusupov wrote:
> Since HTTP/2 needs mux and flow control it = appears to be reasonable to use
> the WS mux and frame format for = HTTP/2, so that HTTP/2 becomes a subprotocol
> of = WS.

This does not seam = reasonable to me. It's hard for me to explain why
but it seems a bit = reversed. In my opinion we should have a common
framing layer = offering MUX and bidir-communications on top of which we
have HTTP = for object retrieval and WS for short interactive exchanges
(could be = seen as less typed data without headers and without = buffering).

 

Forgetting what their original target applications = are,

 

SPDY is a versatile multiplexing protocol with flow = control

- for X key-value = pairs + 1 (possibly endless) binary string

- simple encoding/field, int32 = aligned

- more = overhead

 

WebSocket multiplexing is = one

- for X key-value = pairs + Y (possibly unlimited number of) (possibly endless) = binary strings

- = complicated encoding/field, not int32 = aligned

- less = overhead

 

I = think this is what they are in the context of HTTP/2.0 framing = discussion.

 

SPDY lacks message semantics necessary to lay WS = semantics. But Takashi has been trying to do it by using SPDY's HEADERS = as message boundary signal. It works. (See spdy-dev for = detail)

 

------=_NextPart_000_0058_01CD6A80.E12B93A0-- From w@1wt.eu Wed Jul 25 06:42:27 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342CE21F85B6 for ; Wed, 25 Jul 2012 06:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.515 X-Spam-Level: X-Spam-Status: No, score=-5.515 tagged_above=-999 required=5 tests=[AWL=-3.472, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlfvCoOrF5vj for ; Wed, 25 Jul 2012 06:42:26 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id E6EDD21F85B4 for ; Wed, 25 Jul 2012 06:42:18 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q6PDgCBX015523; Wed, 25 Jul 2012 15:42:12 +0200 Date: Wed, 25 Jul 2012 15:42:12 +0200 From: Willy Tarreau To: Arman Djusupov Message-ID: <20120725134212.GA15475@1wt.eu> References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> <20120725105001.GA14617@1wt.eu> <005701cd6a67$bbdcd500$33967f00$@noemax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005701cd6a67$bbdcd500$33967f00$@noemax.com> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 13:42:27 -0000 Hi Arman, On Wed, Jul 25, 2012 at 04:16:35PM +0300, Arman Djusupov wrote: > I don't see any practical reasons why not to reuse WS for HTTP/2. WS already > looks simply as a subset of HTTP/2, offering only "Mux and > bidir-communication" to which HTTP/2 has to add whatever extra is required. And minor variations such as no latency for WS messages as opposed to possible buffering for HTTP, and possibly a different use meaning that the motivation to analyse either of them differs (eg: an HTTP intermediary would not necessarily be interested in processing short WS frames one at a time, and might probably prefer to forward each byte it receives to the other side). > The difference between a WS message and an HTTP message is only the presence > of the HTTP header, otherwise WS has everything needed to move HTTP requests > and responses in any direction. If WS/2 and HTTP/2 would be sharing the same > framing layer as mentioned by Willy Tarreau, then this common framing layer > will practically be the whole WS/2 because there is nothing extra WS/2 can > offer. It's possible, but as you can see, the fact that there are discussions about how to transport any on top of the other means that there is a huge common part at the bottom layer. > So during the handshake, instead of either WS/2 or HTTP/2, it would be more > like "raw WS/2 or WS/2 + HTTP/2". For the concept of using an entity called "WebSocket" as a generic socket for web usage, I'm 100% for this. However, if we ever want to improve WS to become WS/3 with richer services, we'll need to keep the bottom framing layer for WS/* and HTTP/2. At this point it becomes clearer that we need a common layer (which might or might not be the WS framing). Also as was already said, WS can be manipulated by the application layer and was made for this. So we want the application not to be able to manipulate the lower layer and still manipulate the upper layer. That's another reason to clearly define where the split is needed. Regards, Willy From arman@noemax.com Wed Jul 25 07:52:49 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F58021F85DA for ; Wed, 25 Jul 2012 07:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRw0j1bchk0i for ; Wed, 25 Jul 2012 07:52:48 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2A11E21F8554 for ; Wed, 25 Jul 2012 07:52:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1343227960; x=1343832760; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=evwpQvVBhaDsUpZL+4xTLCk3MKY=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; b=kcygSGyxncw+PycovLRyyDlmvbJzDewiGUZc+LH9wvz4SMt2MFEjGLDNDo1dNw2DsB0aFVxaRBXiAH6b4q5cQKMSZOtgH7mF6xltf4Q03iYC2pGkzXokFKHDdt0S0Jy/iVmBtviAe5XpxDS+6SmEzMed4eo8ixckOw9CVc0lvys= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id JVZ92138; Wed, 25 Jul 2012 17:52:38 +0300 From: "Arman Djusupov" To: "'Willy Tarreau'" References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> <20120725105001.GA14617@1wt.eu> <005701cd6a67$bbdcd500$33967f00$@noemax.com> <20120725134212.GA15475@1wt.eu> In-Reply-To: <20120725134212.GA15475@1wt.eu> Date: Wed, 25 Jul 2012 17:52:09 +0300 Message-ID: <007201cd6a75$1560dd80$40229880$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQF4QXzHQX3/ai5UKZHZE8FhMDtxqwH/aSG6AnfjcEACu1cbbQHPvQuKAnfoRRqXiJPwIA== Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 14:52:49 -0000 Yes, an application can manipulate the WS connection and create its own sub protocols. The protocol header in the WS handshake was introduced exactly to identify the sub-protocol used by an application. But let's not forget that a browser is also an application. A browser may have its own logical channels isolated from the WS-API and may use these channels for any purpose. Preventing a scripted application from using sub-protocols it's not entitled to use is a matter of browser policy. The WS handshake has sufficient negotiation features (sub-protocol and extensions) so that the spec does not have to change when a new sub-protocol or new extensions are created. But if you are suggesting to disassociate WS as framing and mux protocol from the browsers and JS apps into a separate and independent "common framing layer", that could be a good idea. But this will require a new specification... which will practically obsolete the old one. With best regards, Arman -----Original Message----- From: Willy Tarreau [mailto:w@1wt.eu] Sent: Wednesday, July 25, 2012 4:42 PM To: Arman Djusupov Cc: 'Takeshi Yoshino'; hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing Hi Arman, On Wed, Jul 25, 2012 at 04:16:35PM +0300, Arman Djusupov wrote: > I don't see any practical reasons why not to reuse WS for HTTP/2. WS > already looks simply as a subset of HTTP/2, offering only "Mux and > bidir-communication" to which HTTP/2 has to add whatever extra is required. And minor variations such as no latency for WS messages as opposed to possible buffering for HTTP, and possibly a different use meaning that the motivation to analyse either of them differs (eg: an HTTP intermediary would not necessarily be interested in processing short WS frames one at a time, and might probably prefer to forward each byte it receives to the other side). > The difference between a WS message and an HTTP message is only the > presence of the HTTP header, otherwise WS has everything needed to > move HTTP requests and responses in any direction. If WS/2 and HTTP/2 > would be sharing the same framing layer as mentioned by Willy Tarreau, > then this common framing layer will practically be the whole WS/2 > because there is nothing extra WS/2 can offer. It's possible, but as you can see, the fact that there are discussions about how to transport any on top of the other means that there is a huge common part at the bottom layer. > So during the handshake, instead of either WS/2 or HTTP/2, it would be > more like "raw WS/2 or WS/2 + HTTP/2". For the concept of using an entity called "WebSocket" as a generic socket for web usage, I'm 100% for this. However, if we ever want to improve WS to become WS/3 with richer services, we'll need to keep the bottom framing layer for WS/* and HTTP/2. At this point it becomes clearer that we need a common layer (which might or might not be the WS framing). Also as was already said, WS can be manipulated by the application layer and was made for this. So we want the application not to be able to manipulate the lower layer and still manipulate the upper layer. That's another reason to clearly define where the split is needed. Regards, Willy From fenix@google.com Wed Jul 25 10:24:30 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E319821F86C7 for ; Wed, 25 Jul 2012 10:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.476 X-Spam-Level: X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMZ+N+F+UKCT for ; Wed, 25 Jul 2012 10:24:30 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2949721F86B2 for ; Wed, 25 Jul 2012 10:24:30 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1092981ghb.31 for ; Wed, 25 Jul 2012 10:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=bGIiauitw78ObNvJpzEHIOWNfeZ9l60No/0gt+aazHo=; b=m46O/hX241li3js6ftE04njkfxTSATx5t/3dm9ApZ566i6Gzv+stwY/7i2dqy7OWYD deaPtatChYQ33ydsFqzRUdCkt185v/HIWY94y+BBH+5nVC3xOFNh36BLyxzzFEFRbTon 4Lonm//3yG/ItFxira1oGm8yEi44VOYiojH7viZKIyOckXoswNOO11qw5ZW58m7g/lO9 4nZAv42r9OUrQdfVVoWLfHgLseiS6IW/e5XgWjS7J4vGJcS/hr/gops03SLW4GGsKI0H 9VhMjj2lJ+Ju1QIBtyMupIiQmh7sLF/C984jX706/tiXZkRztk9eCjpBU9MP7AqL9XKm Iuuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=bGIiauitw78ObNvJpzEHIOWNfeZ9l60No/0gt+aazHo=; b=ah23DWcO2kNiEhZC6C8KUbDJD4hQZwriVo1MXKX8R9J5i6gObp5I41jItXdwsCBQ6H tvhzbgIOPnMWLXAQqL0yzj5ARzGXy9OpCrQOU0ctnRX0qjiB7RQ7OpiEi49mWFJQx1Sj C9DrEhGwaEldHv986HdD7dz5c4G9AOyd6rNyL2KcfxVaBNjQx2Vd2fO/1rgGSvap8IBK 5h+FIAhhqCkjN2qzOCFO4zsF9oqcSiUX2leSEAFxQx7DI5jF992RZ0VM8YtWEKYHy1Ek wlNL8A3eGKsYFQoa60T2QOjssetyYlNmSUF4MhRBLLI6BtA+o/79IMJpFIJRZjGM5V8m SUgQ== Received: by 10.43.103.196 with SMTP id dj4mr26137583icc.20.1343237069302; Wed, 25 Jul 2012 10:24:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.103.196 with SMTP id dj4mr26137560icc.20.1343237069158; Wed, 25 Jul 2012 10:24:29 -0700 (PDT) Received: by 10.50.82.6 with HTTP; Wed, 25 Jul 2012 10:24:29 -0700 (PDT) In-Reply-To: References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> Date: Wed, 25 Jul 2012 10:24:29 -0700 Message-ID: From: Roberto Peon To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=bcaec5171a695b3b2804c5aac096 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnJ2EF5fbhd4B8crLbgmvsrYLO+bd69sreDOeQp32rZFlUBMeIrfB11QWB1UOrK2FwsiYIR3KCo6x+0Mc3AhJoQ7QdD6P4D+uhTYB4BHyCrysEVb4MeBpPaMTgR6HnPhTdAEkpMz6SXcLoaTdzO5l4YJ53TnN8RxpMCA3e7il0HVbn0FbE= Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 17:24:31 -0000 --bcaec5171a695b3b2804c5aac096 Content-Type: text/plain; charset=ISO-8859-1 Note that the per-message compression is significantly suboptimal for message routers. Many message routers will wish to examine the contents of the message and forward appropriately, especially on the outgoing side of an aggregating proxy. Separate meta-data and content is far preferable when it can be delimited this way. Our current WS design considers basically none of the scalability needs of intermediaries or servers. That is improving, and improving it is essential, but the extensions will continue be kludges. -=R On Wed, Jul 25, 2012 at 4:30 AM, Takeshi Yoshino wrote: > On Wed, Jul 25, 2012 at 7:04 PM, Arman Djusupov wrote: > >> *From:* hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] *On Behalf >> Of *Takeshi Yoshino >> >> *Sent:* Wednesday, July 25, 2012 10:34 AM >> *To:* hybi@ietf.org >> *Subject:* [hybi] HTTP/2.0 framing and WebSocket multiplexing**** >> >> ** ** >> >> * Efficiency of header data transfer**** >> >> - Add SPDY style encoding to AddChannelRequest/Response's Enc type as >> defined in >> http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2.6.10 . This >> makes WebSocket multiplexing as efficient as SPDY to convey HTTP traffic. >> **** >> >> ** ** >> >> If you mean compressing the headers using zlib initialized with a >> predefined dictionary then this would make sense, but we already have >> integrated per-message compression for WS so this option should be enabled >> only if WS compression is not used. >> > > Yes if that combination is efficient enough. > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --bcaec5171a695b3b2804c5aac096 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Note that the per-message compression is significantly suboptimal for messa= ge routers.
Many message routers will wish to examine the contents of t= he message and forward appropriately, especially on the outgoing side of an= aggregating proxy. Separate meta-data and content is far preferable when i= t can be delimited this way.

Our current WS design considers basically none of the s= calability needs of intermediaries or servers.
That is improving,= and improving it is essential, but the extensions will continue be kludges= .

-=3DR


On Wed, Jul 25, 2012 at 4:30 AM, Takeshi Yoshino <tyoshino@google.com> wrote:
On Wed, Jul 25, 2012 at 7:04 PM, Arman Djusupov= <arman@noemax.com> wrote:

<= b>From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = Takeshi Yoshino

Sent: Wednesday, July 25, 201= 2 10:34 AM
To: hybi@ietf.org
Subject: [hybi] HTTP/2.0 framing and WebSocket multiplexing

=A0

* Efficiency of header data transfer

- Add=A0SPDY style encoding to AddChannelRequest/Res= ponse's=A0Enc type as defined in=A0http://to= ols.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2.6.10=A0.=A0Th= is makes WebSocket multiplexing as efficient as SPDY to convey HTTP traffic= .

=A0<= /p>

If you mean comp= ressing the =A0headers using zlib initialized with a predefined dictionary = then this would make sense, but we already have integrated per-message comp= ression for WS so this option should be enabled only if WS compression is n= ot used.=A0


Yes if that combination is eff= icient enough.


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


--bcaec5171a695b3b2804c5aac096-- From bruce@callenish.com Wed Jul 25 19:52:43 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D247B11E808C for ; Wed, 25 Jul 2012 19:52:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY5t0aQId0kw for ; Wed, 25 Jul 2012 19:52:43 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.213.3]) by ietfa.amsl.com (Postfix) with ESMTP id 34DB911E807F for ; Wed, 25 Jul 2012 19:52:43 -0700 (PDT) Received: from [24.108.214.86] (port=57675 helo=[192.168.145.106]) by biz82.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SuEBt-0001uY-2p; Wed, 25 Jul 2012 19:52:41 -0700 Message-ID: <5010B103.70809@callenish.com> Date: Wed, 25 Jul 2012 19:52:51 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Takeshi Yoshino 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 X-Source: X-Source-Args: X-Source-Dir: Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 02:52:44 -0000 On 7/25/2012 12:33 AM, Takeshi Yoshino wrote: > Thanks the authors for preparing this slide > http://tools.ietf.org/agenda/84/slides/slides-84-hybi-0.pdf for the > next f2f meeting. I read through the slides and I don't really understand the objections to using the Websockets framing for both, although I agree with Willy that the framing should be a separate layer that both Websockets and HTTP2.0 run on top of. The initial handshake to upgrade the connection should be changed to reflect that, although I have no suggestions what this framing/mux layer should be called. But once the upgrade is done, there is no need for an upgrade header or connection header in the channel handshake for either WS or HTTP2.0. Non-muxed WS could continue to use the WS 1.0 spec. There were two main objections I saw to using WS framing: 1. Masking. I don't see why HTTP2.0 couldn't just turn off the masking bit. Websocket Message frames from the client sent over the shared framing layer would have the bit set but HTTP2.0 Request frames wouldn't. 2. Variable Length Encodings. Not quite sure what this refers to. Is it the extended payload length field? I can't see why it would be a problem for HTTP2.0 to support this. I guess part of the issue is that the slides are complecting framing with mux, whereas WS has separated the two discussions out. Adopting WS framing does not imply adopting the WS mux proposal to my mind. Certainly we should make sure that both HTTP2.0 and WS have the same MUXing implementation as much as is sensible, but is there a good reason not to reuse the base framing? One final point. This notion of dividing up a space based on modulo n ids is a pattern I find troubling. It automatically assumes there will only ever be n categories, but as this discussion has shown with n going from 2 to 4, that is a big assumption that often bites you down the road. Better to have a field that identifies the channel type, with some reserved bits available so that an extension of types can be designed in later if need be. Although this looks superficially the same (the lowest bits of the ID are defining the channel type) the fact that you use the bits for both the ID and the type means you are overloading the bits and can't easily alter anything later. From tyoshino@google.com Wed Jul 25 21:52:00 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88ADB21F8594 for ; Wed, 25 Jul 2012 21:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7zoTH2InHpA for ; Wed, 25 Jul 2012 21:51:59 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3076F21F858F for ; Wed, 25 Jul 2012 21:51:58 -0700 (PDT) Received: by yenq13 with SMTP id q13so1680606yen.31 for ; Wed, 25 Jul 2012 21:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=ZTWFici3hYaKQu8Kye3LRYl5otHzbxj1WmuHjlGzaic=; b=OWWml4pvn8jHXkYp069BQBXVfeWe0nJPt9Av6bD0wVja8oy+jGk2nR1Yj3Wj+J2QQs jsQ0flSDh0QASBRka3NdYzOYt0HxTvMN6dFZrbciG/2dE8s8eIrUBjom0UEaq/ZFX6s3 65WzVQJUfYmdI+B6G4GdVYRt+JQZ6dC3XbqsOpVwkMc+iRbfPDwNtDwGtq6jlm0mBZUU eBw8d/h4Uy9Chjf5rgJ6oLoIaC8veaJq2QkapumiGfkYfePit0nHbhNgI7tnkZt3E7dZ /b9sFwYCvht/9XPrZUTZA+pNCh5S1pIFuUT/Wfl4PoYDeAPyznixPwDlYqoAkQN0Q6ow plNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=ZTWFici3hYaKQu8Kye3LRYl5otHzbxj1WmuHjlGzaic=; b=jFsf3oyyLU0nDfWTEir1UG+460kj/nWhmksk6/4zpNMcBZHIVG/n1CMhj9ms1CeRRk staEoq0I+RU0NjqzmXD2X0+V6XXHWHM1/ezHe5jlTj5baQ14qV5JuF9so/a8N0wF9arI rFm9ZxFcwrVZ4MtmqZ+JOOwA9AOg0dh5gbOodV1aoe04l10jNyg1hRf1pD5lPEQfwMQv HbJpcjcJn/o0GzzJiWBSVRT9XmjZt4IoBMJx1vHep3L5cUnCdv8jnM5rcsNcUADmC3O1 T7jYiyK5jWeW5QRUm8H8TnhG18y3+oruNhSgqan6n7rC2ta8UvAqFbwva3gcT8Kcfy5k P/9w== Received: by 10.50.94.228 with SMTP id df4mr481099igb.34.1343278318062; Wed, 25 Jul 2012 21:51:58 -0700 (PDT) Received: by 10.50.94.228 with SMTP id df4mr481091igb.34.1343278317953; Wed, 25 Jul 2012 21:51:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Wed, 25 Jul 2012 21:51:35 -0700 (PDT) In-Reply-To: References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> From: Takeshi Yoshino Date: Thu, 26 Jul 2012 13:51:35 +0900 Message-ID: To: Roberto Peon Content-Type: multipart/alternative; boundary=e89a8f235453f9e47d04c5b45a4b X-System-Of-Record: true X-Gm-Message-State: ALoCoQmPoXtcJx1+h3IFtakq5C04ESE7oWChffM7QwJn94i3zFSkcyInWX3BoP0LfQQEbc0SsdYM6u4Z2pcsBg1huT5NUoUaWDoBX6ETnkYvWoznKv+WLjS8QvvZnok/VBZr8QNP1HRdsDjaSBzneZB4gDhOwzo2YeNSnxnzQ27CB5TpxmRVF4Y= Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 04:52:01 -0000 --e89a8f235453f9e47d04c5b45a4b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 26, 2012 at 2:24 AM, Roberto Peon wrote: > Note that the per-message compression is significantly suboptimal for > message routers. > Many message routers will wish to examine the contents of the message and > forward appropriately, especially on the outgoing side of an aggregating > proxy. Separate meta-data and content is far preferable when it can be > delimited this way. > Thanks for reminding this, Roberto. Yes, we discussed LB friendliness and secured the option to compress each logical channel (i.e. Sec-WebSocket-Extensions: compress, mux). In this case, per-message compression doesn't cover mux commands (multiplex control blocks). So, introducing SPDY's header format to AddChannelRequest is still important. --e89a8f235453f9e47d04c5b45a4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 26, 2012 at 2:24 AM, Roberto Peon <f= enix@google.com> wrote:
Note that the per-message compression is significantly suboptimal for messa= ge routers.
Many message routers will wish to examine the contents of t= he message and forward appropriately, especially on the outgoing side of an= aggregating proxy. Separate meta-data and content is far preferable when i= t can be delimited this way.

Thanks for reminding this, Roberto. Yes, w= e discussed LB friendliness and secured the option to compress each logical= channel (i.e. Sec-WebSocket-Extensions: compress, mux). In this case, per-= message compression doesn't cover mux=A0commands=A0(multiplex control b= locks). So, introducing SPDY's header format to AddChannelRequest is st= ill important.

--e89a8f235453f9e47d04c5b45a4b-- From w@1wt.eu Thu Jul 26 00:24:08 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E510D21F867C for ; Thu, 26 Jul 2012 00:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.466 X-Spam-Level: X-Spam-Status: No, score=-5.466 tagged_above=-999 required=5 tests=[AWL=-3.423, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXgvERu86aMI for ; Thu, 26 Jul 2012 00:24:08 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 068DA21F867A for ; Thu, 26 Jul 2012 00:24:07 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q6Q7O3BE019786; Thu, 26 Jul 2012 09:24:03 +0200 Date: Thu, 26 Jul 2012 09:24:03 +0200 From: Willy Tarreau To: Arman Djusupov Message-ID: <20120726072403.GA19758@1wt.eu> References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> <20120725105001.GA14617@1wt.eu> <005701cd6a67$bbdcd500$33967f00$@noemax.com> <20120725134212.GA15475@1wt.eu> <007201cd6a75$1560dd80$40229880$@noemax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007201cd6a75$1560dd80$40229880$@noemax.com> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 07:24:09 -0000 On Wed, Jul 25, 2012 at 05:52:09PM +0300, Arman Djusupov wrote: > Yes, an application can manipulate the WS connection and create its own sub > protocols. The protocol header in the WS handshake was introduced exactly to > identify the sub-protocol used by an application. But let's not forget that > a browser is also an application. A browser may have its own logical > channels isolated from the WS-API and may use these channels for any > purpose. Preventing a scripted application from using sub-protocols it's not > entitled to use is a matter of browser policy. > > The WS handshake has sufficient negotiation features (sub-protocol and > extensions) so that the spec does not have to change when a new sub-protocol > or new extensions are created. But if you are suggesting to disassociate WS > as framing and mux protocol from the browsers and JS apps into a separate > and independent "common framing layer", that could be a good idea. But this > will require a new specification... which will practically obsolete the old > one. I agree, and that's why we were saying WS/2 :-) There is a real opportunity for HTTP and WS to converge and work together, if it happens once in 10 years it would be better not to miss this train. WS wasted one year trying to find how to use HTTP precisely because the transport layer of HTTP was not clearly split/implemented and was not 100% safe to use. By building a common transport layer and application layers on top of it, we have greater chances of getting things right with a clean and safe design. Regards, Willy From tyoshino@google.com Thu Jul 26 01:08:56 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C757C21F86B4 for ; Thu, 26 Jul 2012 01:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.965 X-Spam-Level: X-Spam-Status: No, score=-102.965 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysMBZMJJAuTF for ; Thu, 26 Jul 2012 01:08:56 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F47921F867A for ; Thu, 26 Jul 2012 01:08:55 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1811322ggn.31 for ; Thu, 26 Jul 2012 01:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=c2k2rtMU2/WmgyOb6xxssM8ReNUpvq9OYEyfd7LUOFg=; b=pc2DZxXnqXn1Xb3kVoA3D0DN+i4ZXB3qVGOsDNAUF2s+jqgzfq4moEuKN5rRqhqpW5 LCqjIeSivYNMCp4RU86yt7mpvN2JUmb6tVR8DPR2eZq+Stfp5LVzijR0f2tmcDK16gPB DYTNAB3DTKJRJvteWqnPQwtlsUSv7i1aJvxce2pFdg56wPQkjaiaTL3B36XgFIwrd2Fh 91PuxF01nMC10lHKDnRhQrVyunXu4Lrr6MmMDwV8tQBJmWgQPjOW3ge46Bi8DdtkpcIh VjToGt8AA5dDAXJt6QAhMuHVjzn3Sbcknt1juVhjQTUvmTonjIXTyKlQ2oJaLD/rlalF dGxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=c2k2rtMU2/WmgyOb6xxssM8ReNUpvq9OYEyfd7LUOFg=; b=aYMlZ06KvEg5OMFZUthJYron6HdU7S+sdeCVmeiIh2a4GxtxXcvMi2ZpwPLl9OWmql Y2v9Iu57n4cc9zaXpErSeTQPd7DsrcFl9Jdd/ihLcgoJNmIxuh8Ytm9cFJ1vJ2PGBiOX 6X4UP1yVWQdHNurMaaexEZVCBI1TGjpWp75uBYie3Cj+5ps5g/T8rgQ878Nnb6rcs5hD HH0qDuTZsBlkHiXrNyYPNn8W5bW4FhYnMK/lYVT9czQ9rttXNiHFmoJcL0p9z2wJVSSI 1eN9cs3hxMmOwTDu+se0V+qdZ0uNYSnoUtbAu63xVakyx9QZhHezItcG17xAaJ0DlMe6 ugcA== Received: by 10.42.50.17 with SMTP id y17mr11019565icf.44.1343290135290; Thu, 26 Jul 2012 01:08:55 -0700 (PDT) Received: by 10.42.50.17 with SMTP id y17mr11019559icf.44.1343290135111; Thu, 26 Jul 2012 01:08:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Thu, 26 Jul 2012 01:08:33 -0700 (PDT) In-Reply-To: <007201cd6a75$1560dd80$40229880$@noemax.com> References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> <20120725105001.GA14617@1wt.eu> <005701cd6a67$bbdcd500$33967f00$@noemax.com> <20120725134212.GA15475@1wt.eu> <007201cd6a75$1560dd80$40229880$@noemax.com> From: Takeshi Yoshino Date: Thu, 26 Jul 2012 17:08:33 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=90e6ba1efd3c5569b504c5b71b1f X-System-Of-Record: true X-Gm-Message-State: ALoCoQkmP9Ph49Uk8hbPgMjed/7HHA7SdqIjEBoNKEcrYLi1KCW7guLounKsKMR0U9xY2zqDlPJCj54ODSNgK/FtoVW2GZF2Q2FF9TXWJ+WzvntQ1JRiskbza9qS+dXKIZn17lamI4PLOyMrIrgiejKjp5qeynpk/spaSNLG43azy9pBxthP/Ew= Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 08:08:56 -0000 --90e6ba1efd3c5569b504c5b71b1f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 25, 2012 at 11:52 PM, Arman Djusupov wrote: > Yes, an application can manipulate the WS connection and create its own sub > protocols. The protocol header in the WS handshake was introduced exactly > to > identify the sub-protocol used by an application. But let's not forget that > a browser is also an application. A browser may have its own logical > channels isolated from the WS-API and may use these channels for any > purpose. Preventing a scripted application from using sub-protocols it's > not > entitled to use is a matter of browser policy. > Then, we need to introduce such a blacklist to all browsers before starting HTTP/2.0 servers. I don't want to do that. My claim is only that we can't use "Sec-WebSocket-Protocol" for this purpose. I don't think your idea of layering HTTP as "subprotocol" over WebSocket message semantics nonsense. It's still one of the candidates. > The WS handshake has sufficient negotiation features (sub-protocol and > extensions) so that the spec does not have to change when a new > sub-protocol > or new extensions are created. But if you are suggesting to disassociate WS > as framing and mux protocol from the browsers and JS apps into a separate > and independent "common framing layer", that could be a good idea. But this > will require a new specification... which will practically obsolete the old > one. My approach is trying to find the way to make WebSocket multiplexing good enough taking care of HTTP traffic without making big change (just relaxing masking rule) on WebSocket core protocol. With the changes in my first mail and some more, I believe, WebSocket + WebSocket multiplexing will deserve to be called "HTTP/2.0 framing". --90e6ba1efd3c5569b504c5b71b1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2012 at 11:52 PM, Arman Djusupov <arman@noemax.com><= /span> wrote:
Yes, an application can manipulate the WS connection and create its own sub=
protocols. The protocol header in the WS handshake was introduced exactly t= o
identify the sub-protocol used by an application. But let's not forget = that
a browser is also an application. A browser may have its own logical
channels isolated from the WS-API and may use these channels for any
purpose. Preventing a scripted application from using sub-protocols it'= s not
entitled to use is a matter of browser policy.

Then, we need to introduce such a blacklist to all browsers before = starting HTTP/2.0 servers. I don't want to do that.

My claim is only that we can't use "Sec-WebSocket-Proto= col" for this purpose.=A0I don't think your idea of layering HTTP = as "subprotocol" over WebSocket message semantics nonsense. It= 9;s still one of the candidates.
=A0
The WS handshake has sufficient negotiation features (sub-protocol and
extensions) so that the spec does not have to change when a new sub-protoco= l
or new extensions are created. But if you are suggesting to disassociate WS=
as framing and mux protocol from the browsers and JS apps into a separate and independent "common framing layer", that could be a good idea= . But this
will require a new specification... which will practically obsolete the old=
one.

My approach is trying to find the way = to make WebSocket multiplexing good enough taking care of HTTP traffic with= out making big change (just relaxing masking rule) on WebSocket core protoc= ol.

With the changes in my first mail and some more, I beli= eve, WebSocket + WebSocket multiplexing will deserve to be called "HTT= P/2.0 framing".
=A0
--90e6ba1efd3c5569b504c5b71b1f-- From phil127@gmail.com Thu Jul 26 01:46:27 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F45421F86EB for ; Thu, 26 Jul 2012 01:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rg4qwz+GBabH for ; Thu, 26 Jul 2012 01:46:26 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A6A9321F86B6 for ; Thu, 26 Jul 2012 01:46:25 -0700 (PDT) Received: by bkty7 with SMTP id y7so1033694bkt.31 for ; Thu, 26 Jul 2012 01:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=9jJ7FolZFQbLuT4njn1+yR5+cWuMdbM5mnhi/6kdupM=; b=srOCOtfRQIpN7GZdpkF2M+lxMKvSBRoajehE8FCNTQTRPBAwo1qJItnhkyyNqA8oqF MLRPxM+gdZ/4DPEGQvHttpOCrDJ4CuIeLtuhbRcmfdPeGVAQ9Sn3syfBJjrtZbiy51mm SDd4pAsMdTdCkIrwt4q6GhdkG4tEu8LeppBmaahS+/5pRmCpjrbB7PhqNJyL2BLuZIII qR/RLZj3psumivxF9kmqyqOfrVJ4hfWJlXphdKFyfTCRRmRxJ9VUgU8ZQ9LL1W3l2Yut 3gxQvxGabVU3x2KxVMn4DH5S1f2yHfbDEw2KrjfykJbgeDiGjBXJ/Ia8xa2UcLMjpKWT Y/bg== Received: by 10.204.130.216 with SMTP id u24mr13587583bks.119.1343292384448; Thu, 26 Jul 2012 01:46:24 -0700 (PDT) Received: from [212.201.71.52] (pptp-212-201-71-52.pptp.stw-bonn.de. [212.201.71.52]) by mx.google.com with ESMTPS id 14sm14006595bkq.12.2012.07.26.01.46.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jul 2012 01:46:23 -0700 (PDT) Message-ID: <501103D9.2050800@gmail.com> Date: Thu, 26 Jul 2012 10:46:17 +0200 From: Philipp Serafin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Takeshi Yoshino , Hybi References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> <20120725105001.GA14617@1wt.eu> <005701cd6a67$bbdcd500$33967f00$@noemax.com> <20120725134212.GA15475@1wt.eu> <007201cd6a75$1560dd80$40229880$@noemax.com> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: multipart/alternative; boundary="------------050203070201000008090609" Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 08:46:27 -0000 This is a multi-part message in MIME format. --------------050203070201000008090609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'd like to agree that a protocol blacklist would be a bad idea. In addition the reasons stated, some browsers (e.g. Google Chrome) already have WebSocket support enabled for the public web, after all. Introducing such a blacklist now might cause security risks for users of legacy browsers. (e.g. corporate environments or users who have disabled auto-updating) But since there might be more cases in the future where browsers might want to exchange sensitive data via a websocket-based protocol, maybe it would be useful to introduce some general kind of way to make certain subprotocols unusable for scripting? As the Sec-WebSocket-Extensions can't be manipulated by scripts, how about introducing an additional "pseudo extension". During negiotation, the extension string would contain the names of all "protected" sub protocols as a parameter. Then, a websocket connection using a particular "protected" sub protocol could only be opened if the client announced the protocol both in the Sec-WebSocket-Protocol *and* in the Sec-WebSocket-Extensions field via the pseudo extension. A malicious script could not initiate such a connection since it could not set the pseudo extension. Example: If http/2.0 were a "protected" sub protocol, a valid opening handshake would start like this: GET / HTTP/1.1 Upgrade: websocket Connection: Upgrade ( ... host, origin, ws-key, ws-version, etc ...) Sec-WebSocket-Protocol: http2 Sec-WebSocket-Extensions: protected-protocols;names=http2, (other extensions...) Would such a thing be useful? Regards, Philipp Serafin Am 26.07.2012 10:08, schrieb Takeshi Yoshino: > On Wed, Jul 25, 2012 at 11:52 PM, Arman Djusupov > wrote: > > Yes, an application can manipulate the WS connection and create > its own sub > protocols. The protocol header in the WS handshake was introduced > exactly to > identify the sub-protocol used by an application. But let's not > forget that > a browser is also an application. A browser may have its own logical > channels isolated from the WS-API and may use these channels for any > purpose. Preventing a scripted application from using > sub-protocols it's not > entitled to use is a matter of browser policy. > > > Then, we need to introduce such a blacklist to all browsers before > starting HTTP/2.0 servers. I don't want to do that. > > My claim is only that we can't use "Sec-WebSocket-Protocol" for this > purpose. I don't think your idea of layering HTTP as "subprotocol" > over WebSocket message semantics nonsense. It's still one of the > candidates. --------------050203070201000008090609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

I'd like to agree that a protocol blacklist would be a bad idea. In addition the reasons stated, some browsers (e.g. Google Chrome) already have WebSocket support enabled for the public web, after all.
Introducing such a blacklist now might cause security risks for users of legacy browsers. (e.g. corporate environments or users who have disabled auto-updating)

But since there might be more cases in the future where browsers might want to exchange sensitive data via a websocket-based protocol, maybe it would be useful to introduce some general kind of way to make certain subprotocols unusable for scripting?

As the Sec-WebSocket-Extensions can't be manipulated by scripts, how about introducing an additional "pseudo extension". During negiotation, the extension string would contain the names of all "protected" sub protocols as a parameter. Then, a websocket connection using a particular "protected" sub protocol could only be opened if the client announced the protocol both in the Sec-WebSocket-Protocol *and* in the Sec-WebSocket-Extensions field via the pseudo extension. A malicious script could not initiate such a connection since it could not set the pseudo extension.

Example: If http/2.0 were a "protected" sub protocol, a valid opening handshake would start like this:

GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
( ... host, origin, ws-key, ws-version, etc ...)
Sec-WebSocket-Protocol: http2
Sec-WebSocket-Extensions:  protected-protocols;names=http2,  (other extensions...)

Would such a thing be useful?

Regards,
Philipp Serafin

Am 26.07.2012 10:08, schrieb Takeshi Yoshino:
On Wed, Jul 25, 2012 at 11:52 PM, Arman Djusupov <arman@noemax.com> wrote:
Yes, an application can manipulate the WS connection and create its own sub
protocols. The protocol header in the WS handshake was introduced exactly to
identify the sub-protocol used by an application. But let's not forget that
a browser is also an application. A browser may have its own logical
channels isolated from the WS-API and may use these channels for any
purpose. Preventing a scripted application from using sub-protocols it's not
entitled to use is a matter of browser policy.

Then, we need to introduce such a blacklist to all browsers before starting HTTP/2.0 servers. I don't want to do that.

My claim is only that we can't use "Sec-WebSocket-Protocol" for this purpose. I don't think your idea of layering HTTP as "subprotocol" over WebSocket message semantics nonsense. It's still one of the candidates.

--------------050203070201000008090609-- From tyoshino@google.com Thu Jul 26 04:02:14 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B4521F8744 for ; Thu, 26 Jul 2012 04:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.965 X-Spam-Level: X-Spam-Status: No, score=-102.965 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIwDIpU-R0g1 for ; Thu, 26 Jul 2012 04:02:13 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B610021F870A for ; Thu, 26 Jul 2012 04:02:13 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1987270ghb.31 for ; Thu, 26 Jul 2012 04:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=rzsdGKWq9vTelUrPxuqXMPGmNRJ/UQrcYmIn1H06k2I=; b=PanbD4gGSHBJjji6HHKifWKBihw/xhYDfQl8pktIAKQvCzl8GP+PBi55EcBmLcoJU9 JZszA65rEnzeckmSPKenpzpqXawFxuOWz453EnhWI4P5Uk0VG7vFpGR6s5ZiDpXdlvM9 OAtMatfEn9YC31Yj3pUilG9JkDt7nk7dWiYMJZhW/sNXdCF350gM7tFmwRqxYZrIa896 f+3LUoODzVAap7X5dP4G7wZGw+LJoFVREss7Ldomc4S6eWaM3W1p763aK3XwDVdbrrBY 8Gc/hhKsjkt0PvEQ6S8XWblHuKK4nZeYPVx58mavUISG1AdqjE/+NfuAuDcK9QlKsfJd j6dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=rzsdGKWq9vTelUrPxuqXMPGmNRJ/UQrcYmIn1H06k2I=; b=dgELlbtZwEEGqJlnxiSCEP5WJHYh7sN5rH4pKk11mtkDPZNaMHjdz3cZgO0ku7lXl8 rHZ1WfYWWNSE+bSGsF5qNZMpRhdkEQRkLWXsZhhHUKVg5V7kY4j/QJY8uTbCy2dJU/Qw 19mjvJIvN6lveZ7VnRj9xJ2w/b9xw6haMzn4MaOVQTQjwPlSyeQUndZdLENA+d7O7mml RQ487fQv+3AOwd6kTimLviyoBqFrTSMwBv+/Co00h5Db3O6rF8++Ov+MlLCfPixU3i3L 5yjTrKE8j4SwlQ9ppZP1rj4dP/wKU2wDhMxCk3iayRsxdk7/ONfTJTwmNNrvcHqRFdEF uFEg== Received: by 10.50.209.41 with SMTP id mj9mr1239501igc.23.1343300532841; Thu, 26 Jul 2012 04:02:12 -0700 (PDT) Received: by 10.50.209.41 with SMTP id mj9mr1239493igc.23.1343300532681; Thu, 26 Jul 2012 04:02:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Thu, 26 Jul 2012 04:01:42 -0700 (PDT) In-Reply-To: <5010B103.70809@callenish.com> References: <5010B103.70809@callenish.com> From: Takeshi Yoshino Date: Thu, 26 Jul 2012 20:01:42 +0900 Message-ID: To: Bruce Atherton Content-Type: multipart/alternative; boundary=14dae9340afb13bb2404c5b987ce X-System-Of-Record: true X-Gm-Message-State: ALoCoQmpYtFlnilRBvPI6fP4lpKAISeoU7kqKwnrqBporSKDUT0ZlIgEfKFH/5X1tEuSFOc8kdbbv7U4X3e2vGIuAaLy58eYs/R1HZFU+Vly3/4LM41vF18sgzG5Y9PzA/0IRVJYvF72dFnyG1SnDawSMjOPPNAjjCryXducZ3BjPV/8KuncryA= Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 11:02:15 -0000 --14dae9340afb13bb2404c5b987ce Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 26, 2012 at 11:52 AM, Bruce Atherton wrote: snip > But once the upgrade is done, there is no need for an upgrade header or > connection header in the channel handshake for either WS or HTTP2.0. > Non-muxed WS could continue to use the WS 1.0 spec. > I'll clean up on AddChannelRequest spec. Upgrade, Sec-WebSocket-Key, etc. should be excluded from delta base. > One final point. This notion of dividing up a space based on modulo n ids > is a pattern I find troubling. It automatically assumes there will only > ever be n categories, but as this discussion has shown with n going from 2 > to 4, that is a big assumption that often bites you down the road. Good point. > Better to have a field that identifies the channel type, with some > reserved bits available so that an extension of types can be designed in > later if need be. Although this looks superficially the same (the lowest > bits of the ID are defining the channel type) the fact that you use the > bits for both the ID and the type means you are overloading the bits and > can't easily alter anything later. > Separating the stream identifier space into two for each direction is necessary since each end may initiate stream asynchronously. I don't come up with any other attribute with a risk of collision. By adding some string field, say "channel type", to the AddChannelRequest command, each end can give some meaning like "http", "ws" to the new channel, and then just use its ID for tagging. The other end knows what to do with the channel. I feel that reserving ID number space is over killing. --14dae9340afb13bb2404c5b987ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 26, 2012 at 11:52 AM, Bruce Atherton <bruce@callenish.com> wrote:
snip=A0
But once the = upgrade is done, there is no need for an upgrade header or connection heade= r in the channel handshake for either WS or HTTP2.0. Non-muxed WS could con= tinue to use the WS 1.0 spec.

I'll clean up on AddChannelRequest spe= c. Upgrade, Sec-WebSocket-Key, etc. should be excluded from delta base.
=A0
One final point. This notion of dividing up a space based on modulo n ids i= s a pattern I find troubling. It automatically assumes there will only ever= be n categories, but as this discussion has shown with n going from 2 to 4= , that is a big assumption that often bites you down the road.

Good point.
=A0
Better to have a field that identifies the channel type, with some r= eserved bits available so that an extension of types can be designed in lat= er if need be. Although this looks superficially the same (the lowest bits = of the ID are defining the channel type) the fact that you use the bits for= both the ID and the type means you are overloading the bits and can't = easily alter anything later.

Separating the stre= am identifier space into two for each direction is necessary since each end= may initiate stream asynchronously. I don't come up with any other att= ribute with a risk of collision.

By adding s= ome string field, say "channel type", to the AddChannelRequest co= mmand, each end can give some meaning like "http", "ws"= to the new channel, and then just use its ID for tagging. The other end kn= ows what to do with the channel.

I feel that= reserving ID number space is over killing.
=A0
--14dae9340afb13bb2404c5b987ce-- From tyoshino@google.com Thu Jul 26 04:52:04 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980F421F870B for ; Thu, 26 Jul 2012 04:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.965 X-Spam-Level: X-Spam-Status: No, score=-102.965 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkoWQAtlqGZx for ; Thu, 26 Jul 2012 04:52:03 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9089B21F870A for ; Thu, 26 Jul 2012 04:52:03 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2037310ghb.31 for ; Thu, 26 Jul 2012 04:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=RoMJnOkzrfmjFyPMRfBiX/Mu9SppSyPkLle3dI0h9nc=; b=cD39vyEZmHfFgtXF/YDEkxKtGVuWYdeN4dJ6h2rL1lvpJyPDgP35V+sA6JpustlN8+ YUyr3hFZu0OE5CHX7041oV9yC1j/1EnDT9YPNkK11nXHwNQJVUeOZTAThanJpHIx5+OX QkAq2oOETcz/8JDvStruXw4Wf1RGk1T68Mk/dICqxlYDtVnXzq/tXjXLN7lJZE5ksvwC LjEVr/ZN/WLKMTN4oTufbiVmDPFLnzL/HNkxqEsW6EDCLDQ1qFGKEOnZzpvlKF1IhmHA eNlsQnemRnya6/yiAINxHwXq8p4Ilf91giDnZ/0h6MfnCE8qOQDyIlkk8SO9I1YMy7dP cZFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=RoMJnOkzrfmjFyPMRfBiX/Mu9SppSyPkLle3dI0h9nc=; b=AL3+aPO8F3P3ocTH1m5fpnSFLIvtfXLKZagIkCwAmuamLqA5ipx+6mTSi+QabmV5Dy S/WG6QZSMvnnxQVJZV/Gh3YxcNUC1zt1bnJo4LDSt7AReNQyzUkME8GiZr/1UrzKvxGe PLAPxiW+3kBm8KsseK+2fhkC01X28Fj5mmPsZl8bvYVYF1luCNoyZf64otLhtiiAW34Z TTV/cv7Y8tkOk8x1t7cyUccF3Cot4JgLDlGQSl+y6xPMUCsd73kFE6mCBrL7cS2qjcKJ wfWErG+7wiQJcQeglmV91nXVvxD65u5nXrNHf1LfJYt2XI3iK/z2IoSkRogmePVGL9mF tPWQ== Received: by 10.50.209.41 with SMTP id mj9mr1344252igc.23.1343303522772; Thu, 26 Jul 2012 04:52:02 -0700 (PDT) Received: by 10.50.209.41 with SMTP id mj9mr1344243igc.23.1343303522627; Thu, 26 Jul 2012 04:52:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Thu, 26 Jul 2012 04:51:42 -0700 (PDT) In-Reply-To: <501103D9.2050800@gmail.com> References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> <20120725105001.GA14617@1wt.eu> <005701cd6a67$bbdcd500$33967f00$@noemax.com> <20120725134212.GA15475@1wt.eu> <007201cd6a75$1560dd80$40229880$@noemax.com> <501103D9.2050800@gmail.com> From: Takeshi Yoshino Date: Thu, 26 Jul 2012 20:51:42 +0900 Message-ID: To: Philipp Serafin Content-Type: multipart/alternative; boundary=14dae9340afb4ab25704c5ba39a7 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmVi1FXDyDdn539peGTgdgUa/ggJjijm31Gmy6Qbh0ZyDID7gSkIDDPUIc9PnYVrA/DqnxYbcmovGX2Qo2UqLqaruavhlB2Wu9raUEZ4mzR5tdPiNZbmcLkXOsVLD5I+vU15xu/39WD8Dloq6kNXkSZDF+Xi+vvoWrz7ggKT6cjUkGCixU= Cc: Hybi Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 11:52:04 -0000 --14dae9340afb4ab25704c5ba39a7 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 26, 2012 at 5:46 PM, Philipp Serafin wrote: snip > As the Sec-WebSocket-Extensions can't be manipulated by scripts, how > about introducing an additional "pseudo extension". During negiotation, the > extension string would contain the names of all "protected" sub protocols > as a parameter. > Maybe, you suggested this because it's worthwhile to have such a common pseudo extension defined so that - we can announce that it's NOP, so intermediaries don't have to worry about it. - we don't have to define extensions for each of such subprotocols. Good idea, I think. > Then, a websocket connection using a particular "protected" sub protocol > could only be opened if the client announced the protocol both in the > Sec-WebSocket-Protocol *and* in the Sec-WebSocket-Extensions field via the > pseudo extension. > Is this matching necessary? --14dae9340afb4ab25704c5ba39a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 26, 2012 at 5:46 PM, Philipp Serafin <phil127@gmail.com>= ; wrote:
snip
=20 =20 =20
As the Sec-WebSocket-Extensions can't be manipulated by script= s, how about introducing an additional "pseudo extension". Dur= ing negiotation, the extension string would contain the names of all "protected" sub protocols as a parameter.

Maybe, you suggested this because it's worth= while to have such a common pseudo extension defined=A0so that
- we can announce that it's NOP, so intermediaries don't have to wo= rry about it.
- we don't have to define extensions for each o= f such subprotocols.

Good idea, I think.
=A0
Then, a websocket connection using a particular "protected" sub protocol coul= d only be opened if the client announced the protocol both in the Sec-WebSocket-Protocol *and* in the Sec-WebSocket-Extensions field via the pseudo extension.

Is this matching necessary?
=A0
--14dae9340afb4ab25704c5ba39a7-- From tyoshino@google.com Thu Jul 26 05:04:16 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B02521F8750 for ; Thu, 26 Jul 2012 05:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5PIKHlvxlEk for ; Thu, 26 Jul 2012 05:04:15 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A048521F873B for ; Thu, 26 Jul 2012 05:04:15 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2050652ghb.31 for ; Thu, 26 Jul 2012 05:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=lRuj0qykSiITQXXcod15lzfAHTQnLTyQN4SRr6BuWSY=; b=ig5pdG8kYI8mbGUpVzWnBGzcO4qzJJXx4k7oevp6q51ItSyxJWPnKeRdtXbjzqHKpd Oya4uT9wpYyzWHFdDTporvclYhxscGdwtkpRaO9ulKz8Cu+K31SHIsC889u7zISV//Ao JDV0v/4I8m4m2Y7+nv+nXVAj/vY035Afd9+D84O0uIVoVyj2LydV/YqxhxwCXt/V3Shk nAddgy+o2p23PeeQeWyIcwAlRRfNvS4oVwXZ9bjnc3VE6/Bf28hvpm8p7wvhWdFQ+kcy qEukERVb+tz4jc0xxvFvFDHE9qLfZMSEiZSINn4BQHkmpFH7egJpuKCM3l4quN198qW4 ax0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=lRuj0qykSiITQXXcod15lzfAHTQnLTyQN4SRr6BuWSY=; b=eWyE049gYcqk30VJ/EGhgyG61e1Gz3aTqPvLBSA371OOvw9t21y5nvGyHMUwtbNCoR LYSEl7I8HwJi1e1YCy8SB4P1TPhRS8oQdz+e1/gbcm36Gk8nPGJo+L4dSQ3LO8KB2bLK aUAHqJ1ffMNfMnWZVGqjrSSKjyxfQkWz4RWHS9qHFH3BbOAJNOljiq2+iinJLi4a7Adc xPpObIct0oylu0FKWcWGr1lo67UljyWgTzbkySlI843/fxieEJf3FW1gaYI/uL9M6EY+ JfK+A2xd+ESH3YbqUp743gt28M09qBLwN39v5QV9uWad0pp1GSsYGzea4WAz39d5+nXj L9fQ== Received: by 10.50.186.196 with SMTP id fm4mr1348805igc.34.1343304255024; Thu, 26 Jul 2012 05:04:15 -0700 (PDT) Received: by 10.50.186.196 with SMTP id fm4mr1348798igc.34.1343304254904; Thu, 26 Jul 2012 05:04:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.80 with HTTP; Thu, 26 Jul 2012 05:03:54 -0700 (PDT) In-Reply-To: References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> <20120725105001.GA14617@1wt.eu> <005701cd6a67$bbdcd500$33967f00$@noemax.com> <20120725134212.GA15475@1wt.eu> <007201cd6a75$1560dd80$40229880$@noemax.com> <501103D9.2050800@gmail.com> From: Takeshi Yoshino Date: Thu, 26 Jul 2012 21:03:54 +0900 Message-ID: To: Philipp Serafin Content-Type: multipart/alternative; boundary=14dae9340fe7f0598004c5ba6427 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn4R4D5V2nZ4rap9ZKiEygR5rmVPL9Hv3cRBrHyQJxRfwR955PYxIAK79Sx3TOIuJwkQZxjXlxjUAQQMSMJrp1DoBIuV8rmW7DkRfheFEnplfMl9kFq9aKwqk0MNG5v/u6LC78eLAWWdN9xY/lty5QziNiw0XX5N+uD7NUHeRscllZ8viM= Cc: Hybi Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 12:04:16 -0000 --14dae9340fe7f0598004c5ba6427 Content-Type: text/plain; charset=ISO-8859-1 It's ad-hoc, but we can also use presence of the Origin header. If the application doesn't need it, clients can authenticate themselves as non-browser by not sending it. --14dae9340fe7f0598004c5ba6427 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It's ad-hoc, but we can also use presence of the Origin header. If the = application doesn't need it, clients can authenticate themselves as non= -browser=A0by not sending it. --14dae9340fe7f0598004c5ba6427-- From tyoshino@google.com Fri Jul 27 01:19:34 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDAE21F85CE for ; Fri, 27 Jul 2012 01:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUEoPjBLfKpb for ; Fri, 27 Jul 2012 01:19:33 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB3021F85AD for ; Fri, 27 Jul 2012 01:19:31 -0700 (PDT) Received: by lagv3 with SMTP id v3so1990700lag.31 for ; Fri, 27 Jul 2012 01:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=Tt70M5d18nI1kWrYoBiNPFShPDLSxIjaxmhq6sqbV3s=; b=AFcN4khdbexz2A67LnnWaagdyW7CE2O+9oNEW3jk1KwBRkzg51woUwOA+0S830bDQ6 r0E9FLeykqM0GJsZJEEQSI7j6n8ec2gz4vpNG/K2sXBXxpzT2U8Im0tn28m5EOqgUlL9 fdhB7RKPy9C525eU0zlNNplpy4VAea0Jp32yAysZEHum4D9dpZ8NZGkigcRwXsPjdvdk qvWGwqeMRWMkP4PYtvFo/AtGy1KmFfakc2QO+zfqnys0Qd+JZlcVHSi9hrMPslRIweuy +rDuWwRLAtBbO+A0eq+ZSHrPKiOZsW/l/DfSSmHxFbJyw2XzS3uwm9ZqBqsn/Zu9gnNa mcWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=Tt70M5d18nI1kWrYoBiNPFShPDLSxIjaxmhq6sqbV3s=; b=hg8e29khKB3PSSFx6a/8CWB74n1DR73EQovYL5mze5LpwD5ur8rgVauwx7Y3aIIYba zqFs4vL+QY4ppp7x0aRmtPdGLSnrTq1b+Ub0fM+Kb8p3SBG3hv87j9gfN/fOFp+2H6km sW3e41Pn7uxIBhZ4ryeS7ic9jWU2Ss6As9m5YSUvruVHT3+58sUKz/qM7IWdjX0rBSKk qFY6Q+83m/yrawMb6uyO046EzTHndhNA7AMMQfIZHPXtYNoKiYFWldKotuxxX9o49C1d Xpbk9IsoV3O3CRaunBAP9zSJc92ug87AqlynvmIH3BD+qHZjsXmVXvkm30jegS5SJo3s OCig== Received: by 10.112.41.130 with SMTP id f2mr1047753lbl.5.1343377170881; Fri, 27 Jul 2012 01:19:30 -0700 (PDT) Received: by 10.112.41.130 with SMTP id f2mr1047749lbl.5.1343377170761; Fri, 27 Jul 2012 01:19:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.90.171 with HTTP; Fri, 27 Jul 2012 01:19:10 -0700 (PDT) From: Takeshi Yoshino Date: Fri, 27 Jul 2012 17:19:10 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=485b390f79aa1009c304c5cb5fec X-System-Of-Record: true X-Gm-Message-State: ALoCoQlFIVQsVM4Hkd/VvmtbebF1nJ1ebftHp0wX/KxMXTN7rfy4fqlHWiS1noCO9zGFgspYh4wBplNFnc/xiSoO7y7DSIKLYB2PT/y8L7JBqV0jim6mQ+PdEr2I/6tbTIKlUMVABqxYbHShfh0O6jnIgYIb+KuCzNFZFbnfWPIhZB5csRWxSl8= Subject: [hybi] Revising handshake and AddChannelRequest considering HTTP/2.0 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 08:19:35 -0000 --485b390f79aa1009c304c5cb5fec Content-Type: text/plain; charset=ISO-8859-1 === First, clarify AddChannelRequest base spec === Let's break down headers in handshake. Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Version: 13 Sec-WebSocket-Extensions: ext-for-logical-ch, mux, ext-for-physical-conn These headers (except for ext-for-logical-ch) are meaningful only when performing HTTP Upgrade and establishing physical connection. GET /chat HTTP/1.1 Host: server.example.com Sec-WebSocket-Protocol: chat, superchat Origin: http://example.com Cookie: foobar Sec-WebSocket-Extensions: ext-for-logical-ch Any-Other-Header: Its-Value These headers determine by which virtual server / service and how the logical channel are handled. So, the initial delta encoding base should consist of only these headers. ( It looks like moving these headers to mux's extension parameter make sense. But please note that we can't do it because of the requirement that WebSocket server w/o mux support should be able to accept the connection by just rejecting mux extension. Like this: HTTP/1.1 101 Switching Protocols ... Sec-WebSocket-Extensions: ext-for-logical-ch ... ) ---- Response headers are also broken down into two groups. The following headers should be excluded from delta encoding base. Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= (It's off topic but needs discussion whether we should send reply to implicitly opened channel by physical channel handshake response or we should send a separate AddChannelResponse for that. The latter allows opening mux connection even when the request for implicitly opened channel is bad e.g. 404) === Negotiation of logical channel protocol capability === So, how should we negotiate HTTP capability? I propose that we'll add "protocol" extension parameter. The server announces supported logical channel protocols. WebSocket server w/o HTTP/2.0 support announces only ws (or may omit the parameter) like this: Sec-WebSocket-Extensions: ext-for-logical-ch, mux; protocol="ws", ext-for-physical-conn Clients has to fall back to normal HTTP to send HTTP requests. An HTTP/2.0 server supporting both protocol announces both like this: Sec-WebSocket-Extensions: ext-for-logical-ch, mux; protocol="ws, http", ext-for-physical-conn ---- Does everything above work well when an HTTP request is the initiator? It's often that an HTTP request precedes WebSocket connection attempt. Actually, current WebSocket handshake + extension cannot provide clean way path for this. Current bootstrap of WebSocket multiplexing allows for fallback to non-muxed WebSocket connection without extra RTT. It's good but for this case, we don't want to establish an unnecessary WebSocket connection. There's no way to prevent existing non-mux capable WebSocket servers from accepting HTTP/2.0 bootstrap by mistake. So for this case the differentiation between WebSocket and HTTP/2.0 needs to be done by Upgrade type. GET /meaningless HTTP/1.1 Connection: Upgrade Upgrade: http2 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Extensions: mux; protocol="ws, http", ext-for-physical-conn Just headers for upgrade and security are incorporated. Mux will be established but default channel won't be opened. WebSocket servers w/o mux support rejects this handshake. If over NPN, Sec-WebSocket-Extensions: mux; protocol="ws, http", ext-for-physical-conn This is the only information to exchange. --485b390f79aa1009c304c5cb5fec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=3D=3D=3D First, clarify AddChannelRequest base spec =3D=3D=3D

Let's break down headers in handshake.

=
=A0 Upgrade: websocket
=A0 Connection: Upgrade
=A0 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ=3D=3D
=A0 Sec-WebSocket-Version: 13
=A0 Sec-WebSocket-Extensions: = ext-for-logical-ch, mux, ext-for-physical-conn

The= se headers (except for ext-for-logical-ch) are meaningful only when perform= ing HTTP Upgrade and establishing physical connection.

=A0 GET /chat HTTP/1.1
=A0 Host:=A0server.example.com
=
=A0 Sec-WebSocket-Protocol: chat, superchat
=A0 Origin:=A0http://example.com
=A0 Cookie: foobar
=A0 Sec-WebSocket-Extensions: ext-for-log= ical-ch
=A0 Any-Other-Header: Its-Value

These headers determine by which = virtual server / service and how the logical channel are handled. So, the i= nitial delta encoding base should consist of only these headers.

(
It looks like moving these headers to mux&#= 39;s extension parameter make sense. But please note that we can't do i= t because of the requirement that=A0WebSocket server w/o mux support should= be able to accept the connection=A0by just rejecting mux extension. Like t= his:

=A0 HTTP/1.1 101 Switching Protocols
=A0 ...<= /div>
=A0 Sec-WebSocket-Extensions: ext-for-logical-ch
=A0 ..= .
)

----

Respon= se headers are also broken down into two groups. The following headers shou= ld be excluded from delta encoding base.

=A0 Upgrade: websocket
=A0 Connection: U= pgrade
=A0 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=3D

(It's=A0off topic but needs discussion wh= ether we should send reply to implicitly opened channel by physical channel= handshake response or we should send a separate AddChannelResponse for tha= t. The latter allows opening mux connection even when the request for impli= citly opened channel is bad e.g. 404)



=3D=3D=3D =A0Negotiation = of logical channel protocol capability =3D=3D=3D

S= o, how should we negotiate HTTP capability?=A0I propose that we'll add = "protocol" extension parameter. The server announces supported lo= gical channel protocols.

WebSocket server w/o HTTP/2.0 support announces only ws= (or may omit the parameter) like this:

=A0 Sec-WebSocket-Extensions: ext-for-logical-ch, mux; p= rotocol=3D"ws", ext-for-physical-conn

Clients has to fall back to normal HTTP to send HTTP re= quests.

An HTTP/2.0 server supporting both pr= otocol announces both like this:

=A0 Sec-WebSocket-Extensions: ext-for-logical-ch,= mux; protocol=3D"ws, http", ext-for-physical-conn

----

Does everything above work well when an HTTP request is the initiator? It&#= 39;s often that an HTTP request precedes WebSocket connection attempt. Actu= ally, current WebSocket handshake + extension cannot provide clean way path= for this.

Current bootst= rap of WebSocket multiplexing allows for fallback to non-muxed WebSocket co= nnection without extra RTT. It's good but for this case, we don't w= ant to establish an unnecessary WebSocket connection. There's no way to= prevent existing non-mux capable WebSocket servers from accepting HTTP/2.0= bootstrap by mistake.

So for this case the differentiation between WebSocket = and HTTP/2.0 needs to be done by Upgrade type.

=A0 GET /meaningless HTTP/1.1
= =A0 Connection: Upgrade
=A0 Upgrade: http2
=A0 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub2= 5jZQ=3D=3D
=A0 Sec-WebSocket-Extensions: mux; protocol=3D"ws= , http", ext-for-physical-conn

Just headers for upgrade and security are incorporated.=A0Mux will be = established but default channel won't be opened. WebSocket servers w/o = mux support rejects this handshake.

If over NPN,

=A0 Sec-WebSocket-Extensions: mux; protocol=3D&quo= t;ws, http", ext-for-physical-conn

This= is the only information to exchange.

--485b390f79aa1009c304c5cb5fec-- From phil127@gmail.com Fri Jul 27 02:43:53 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D512321F8602 for ; Fri, 27 Jul 2012 02:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwOzVGOSxuFh for ; Fri, 27 Jul 2012 02:43:52 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 795CF21F8606 for ; Fri, 27 Jul 2012 02:43:52 -0700 (PDT) Received: by eaaa11 with SMTP id a11so485988eaa.31 for ; Fri, 27 Jul 2012 02:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=ifaS1s5fjBWGRgMm3RUU9abHuadnm5/pggl/DiOlHRM=; b=dJVIRTrCQe69piL8d4J82ERZ5ZDnMSArnU+r39gkMHpj5VVyaAoKkqwgw4P5OjGwhC YY5Q2pssSEyP6zBoZWU+Apj5GxgKO/Qm+QzZORS20bfvkFzIHSa2qnFZJLTBoRFgQJ92 UDvfsvAa18BysshdDk3LuzPn1surHninoZVdsS3A00uowEWrv0pVBVRkR5Q9MglnVHq/ EsgIzMjf8BlrSpSWanvS70kXUH5b3qnHjrkGqQVYRVlkLwaUeX/bzxY1rJhJRg7NGfD3 RW9z87UDlKsV9GJFnE/9ON1Jm5Gqz8otI3iTnrvCEVUQfj5m7CeOXHIvWqHMchUE4192 JJdQ== Received: by 10.14.184.133 with SMTP id s5mr1912855eem.31.1343382231686; Fri, 27 Jul 2012 02:43:51 -0700 (PDT) Received: from P2 ([2001:638:407:6844:94a0:88fe:925c:e595]) by mx.google.com with ESMTPS id g46sm4587107eep.15.2012.07.27.02.43.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jul 2012 02:43:50 -0700 (PDT) From: "Philipp Serafin" To: "'Takeshi Yoshino'" References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> <20120725105001.GA14617@1wt.eu> <005701cd6a67$bbdcd500$33967f00$@noemax.com> <20120725134212.GA15475@1wt.eu> <007201cd6a75$1560dd80$40229880$@noemax.com> <501103D9.2050800@gmail.com> In-Reply-To: Date: Fri, 27 Jul 2012 11:43:43 +0200 Message-ID: <113701cd6bdc$507144b0$f153ce10$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1138_01CD6BED.13FA89E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF4QXzHQX3/ai5UKZHZE8FhMDtxqwH/aSG6AnfjcEACu1cbbQHPvQuKAnfoRRoBntpTWQKhiLJYAVo9LWECrRu4YpdJHqtA Content-Language: de Cc: 'Hybi' Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 09:43:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1138_01CD6BED.13FA89E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Then, a websocket connection using a particular "protected" sub protocol could only be opened if the client announced the protocol both in the Sec-WebSocket-Protocol *and* in the Sec-WebSocket-Extensions field via the pseudo extension. Is this matching necessary? Well, this might theoretically allow clients to offer both protected and non-protected protocols during negiotation. I realize though that this use-case is mostly already covered by extensions. So, on second thought, it's probably not necessary. It's ad-hoc, but we can also use presence of the Origin header. If the application doesn't need it, clients can authenticate themselves as non-browser by not sending it. This would work, too - however, wouldn't that make it harder to extend the Origin security model to protocols like HTTP2? These protocols would then have to define their own equivalent to the Origin header. ------=_NextPart_000_1138_01CD6BED.13FA89E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Then, a websocket connection using a = particular "protected" sub protocol could only be opened if = the client announced the protocol both in the Sec-WebSocket-Protocol = *and* in the Sec-WebSocket-Extensions field via the pseudo = extension.

 

Is this matching = necessary?

 

Well, this might theoretically allow clients to offer both protected = and non-protected protocols during negiotation. I realize though that =  this use-case is mostly already covered by extensions. So, on = second thought, it’s probably not = necessary.

 

It's ad-hoc, but we can also use presence of the Origin = header. If the application doesn't need it, clients can authenticate = themselves as non-browser by not sending it. =

 

This would work, too – however, wouldn’t that make it = harder to extend the Origin security model to protocols like HTTP2? = These protocols would then have to define their own equivalent to the = Origin header. =

------=_NextPart_000_1138_01CD6BED.13FA89E0-- From tyoshino@google.com Fri Jul 27 06:42:18 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D3321F86AF for ; Fri, 27 Jul 2012 06:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va3N3dDZuaJQ for ; Fri, 27 Jul 2012 06:42:18 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D936B21F86A1 for ; Fri, 27 Jul 2012 06:42:17 -0700 (PDT) Received: by lagv3 with SMTP id v3so2189587lag.31 for ; Fri, 27 Jul 2012 06:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=ozUTf3oT9RGxoXIsB/PVfI0gEIdTRpbOAn36+RLe5hA=; b=B2/Hj7k4xpiBmYn3NZw78K/jtlvBF32uvJsvKR+zbJ74Ckg9bEvsx9Bjq79Anp70hL B75ScxXv0he6SUKZapc/ytqur3foR7Sd1h4LOJCsAzRtI+cYA0jZbN1wLUv3grRIFtC/ TO91cLosGWopGNScT2dfHdOzMi4NlwlPwZrO9pUAGKeQPcs3C2y14/y7iRPib/oYOg2w ZhegROgHa0385hrkgi3nofIfcsHtx8hxWy2ur29yaUOgQ6w97JO/CKTkw2Ik8JNTPW9r uoc5cpiKUj4MVCGL54WxshgUi6duyeXlr0Ny8f6VCpxw7vX9k3ttS1OkKZzS63hPlWtD +kGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=ozUTf3oT9RGxoXIsB/PVfI0gEIdTRpbOAn36+RLe5hA=; b=FZmUqydglJ34W6fqYP8SjDo5w8oABcuHuZX9xwa4/3j+lY7P5XFpAXxKrPYszdagwf aG+j1g39spGpvH9Iy0sEyh0W7c0NTG0bHP2vMtQfaJt+Nd1LKK7CIKx6wl4QjChwXqFi gQ5KSL34vcxPEwgILya369qpf8jJVHNUhPXCKhy5nwL7Vgy9+kDZzUAp0oyFVPfBq9HP n0JZKVi8R8Zoqf303ByC/L/FWow1TQInZHyP5w5FM1c12XioOgvDL5LupFvtMWX0JEf3 Iq98CkTPQcv+ryFuNmues2uuJJis5UHVFicKrWkzDhq4jNUTSl2GTKASGl+QKX13FQRn jjWQ== Received: by 10.112.42.228 with SMTP id r4mr1422372lbl.4.1343396536755; Fri, 27 Jul 2012 06:42:16 -0700 (PDT) Received: by 10.112.42.228 with SMTP id r4mr1422366lbl.4.1343396536505; Fri, 27 Jul 2012 06:42:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.90.171 with HTTP; Fri, 27 Jul 2012 06:41:56 -0700 (PDT) In-Reply-To: <113701cd6bdc$507144b0$f153ce10$@gmail.com> References: <003101cd6a4c$e5e0b4e0$b1a21ea0$@noemax.com> <20120725105001.GA14617@1wt.eu> <005701cd6a67$bbdcd500$33967f00$@noemax.com> <20120725134212.GA15475@1wt.eu> <007201cd6a75$1560dd80$40229880$@noemax.com> <501103D9.2050800@gmail.com> <113701cd6bdc$507144b0$f153ce10$@gmail.com> From: Takeshi Yoshino Date: Fri, 27 Jul 2012 22:41:56 +0900 Message-ID: To: Philipp Serafin Content-Type: multipart/alternative; boundary=e0cb4efe339059d46404c5cfe1cb X-System-Of-Record: true X-Gm-Message-State: ALoCoQlC720VURLWSAr9q3nJUQ7PhnDr9HANr4J5oKavCz0NDtFq/hhx4kXH+JBdYIj4Uymv5q1Fkthmd6Uj+ZLGKLkRoM+gHHsGvz0PGDfweAKXWge0mhIVHLuIvtWN87g9/p0iDWIy9+kpQ6tfM9yhJpuHTB6ZQmNbydfeDMSQTLAXDOSW4Ew= Cc: Hybi Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 13:42:19 -0000 --e0cb4efe339059d46404c5cfe1cb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Jul 27, 2012 at 6:43 PM, Philipp Serafin wrote: > It's ad-hoc, but we can also use presence of the Origin header. If the > application doesn't need it, clients can authenticate themselves as > non-browser by not sending it. > > ** ** > > This would work, too =96 however, wouldn=92t that make it harder to exten= d the > Origin security model to protocols like HTTP2? These protocols would then > have to define their own equivalent to the Origin header. **** > I assumed that in the idea that we realize HTTP/2.0 as a WebSocket subprotocol as Arman suggested, the HTTP laid over WebSocket exchanges full HTTP request data over WebSocket messages. The Origin header of WebSocket (X) tells the origin of the application (Y) right on top of X. I think Y should have its own header to provide security model for the next application (Z) on top of Y as you say. Y =3D HTTP as WebSocket subprotocol Z =3D XHR request for example Y's origin is the UA in this case. It's proven to the server by not sending Origin of X. This is my suggestion above. Y send its own Origin header for Z. --e0cb4efe339059d46404c5cfe1cb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 27, 2012 at 6:43 PM, Philipp Serafin= <phil127@gmail.com> wrote:

It's ad-hoc, but we can also use presence of the Ori= gin header. If the application doesn't need it, clients can authenticat= e themselves as non-browser=A0by not sending it.

=A0

This would work, too =96 however,= wouldn=92t that make it harder to extend the Origin security model to prot= ocols like HTTP2? These protocols would then have to define their own equiv= alent to the Origin header.


I assumed that in the idea that we = realize=A0HTTP/2.0=A0as a WebSocket subprotocol as Arman suggested, the HTT= P laid over WebSocket exchanges full HTTP request data over WebSocket messa= ges.

The Origin header of WebSocket (X) tells the origin of = the application (Y) right on top of X. I think Y should have its own header= to provide=A0security model=A0for the next application (Z) on top of Y as = you say.

Y =3D HTTP as WebSocket subprotocol
Z =3D XHR= request for example

Y's origin is the UA in t= his case. It's proven to the server by not sending Origin of X. This is= my suggestion above.

Y send its own Origin header for Z.
=A0
--e0cb4efe339059d46404c5cfe1cb-- From bruce@callenish.com Mon Jul 30 11:20:39 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791F421F85AC for ; Mon, 30 Jul 2012 11:20:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlIju2Fs3DC6 for ; Mon, 30 Jul 2012 11:20:38 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.213.3]) by ietfa.amsl.com (Postfix) with ESMTP id 4C91A21F8505 for ; Mon, 30 Jul 2012 11:20:38 -0700 (PDT) Received: from [24.108.214.86] (port=61926 helo=[192.168.145.106]) by biz82.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Svua0-00040G-Mb; Mon, 30 Jul 2012 11:20:33 -0700 Message-ID: <5016D07C.2030508@callenish.com> Date: Mon, 30 Jul 2012 11:20:44 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Takeshi Yoshino References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080901090905050409030104" 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 X-Source: X-Source-Args: X-Source-Dir: Cc: hybi@ietf.org Subject: Re: [hybi] Revising handshake and AddChannelRequest considering HTTP/2.0 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 18:20:39 -0000 This is a multi-part message in MIME format. --------------080901090905050409030104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12-07-27 01:19 AM, Takeshi Yoshino wrote: > === First, clarify AddChannelRequest base spec === > > Let's break down headers in handshake. > > Upgrade: websocket > Connection: Upgrade > Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== > Sec-WebSocket-Version: 13 > Sec-WebSocket-Extensions: ext-for-logical-ch, mux, ext-for-physical-conn > > These headers (except for ext-for-logical-ch) are meaningful only when > performing HTTP Upgrade and establishing physical connection. I agree for most of these, but I am uncertain about the Sec-WebSocket-Key. The point of that (and the Sec-WebSocket-Accept) is to guarantee that both ends are actually WS endpoints. Are there not usecases where a datacenter frontend might split a muxed connection and send the channels to different servers? If so, I think we need to validate all the endpoints of channels by sending a nonce and receiving the correct hash back. Unless people have changed their minds about the usefulness of this technique. > > GET /chat HTTP/1.1 > Host: server.example.com > Sec-WebSocket-Protocol: chat, superchat > Origin: http://example.com > Cookie: foobar > Sec-WebSocket-Extensions: ext-for-logical-ch > Any-Other-Header: Its-Value > > These headers determine by which virtual server / service and how the > logical channel are handled. So, the initial delta encoding base > should consist of only these headers. > > ( > It looks like moving these headers to mux's extension parameter make > sense. But please note that we can't do it because of the requirement > that WebSocket server w/o mux support should be able to accept the > connection by just rejecting mux extension. Like this: > > HTTP/1.1 101 Switching Protocols > ... > Sec-WebSocket-Extensions: ext-for-logical-ch > ... > ) Do you mean adding any number of headers as parameters to the mux extension declaration in the Sec-Websocket-Extensions header? A list of headers inside a single header seems needlessly complicated to me, even without the need for a fallback for non-muxing servers. > > Response headers are also broken down into two groups. The following > headers should be excluded from delta encoding base. > > Upgrade: websocket > Connection: Upgrade > Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= > > (It's off topic but needs discussion whether we should send reply to > implicitly opened channel by physical channel handshake response or we > should send a separate AddChannelResponse for that. The latter allows > opening mux connection even when the request for implicitly opened > channel is bad e.g. 404) IMHO the 404 should result in the connection being handled the same way it would for an HTTP XHR request. Ditto for 300 statuses where the resource might have moved to another server that requires a different connection to be established. What if, in a particular session, there was only going to be that one channel request that had failed? A useless connection would be hanging around for no reason. If there is a second channel request that would be successful, then that can be the implicitly opened channel that establishes the mux connection. > > === Negotiation of logical channel protocol capability === > > So, how should we negotiate HTTP capability? I propose that we'll add > "protocol" extension parameter. The server announces supported logical > channel protocols. > > WebSocket server w/o HTTP/2.0 support announces only ws (or may omit > the parameter) like this: > > Sec-WebSocket-Extensions: ext-for-logical-ch, mux; protocol="ws", > ext-for-physical-conn > > Clients has to fall back to normal HTTP to send HTTP requests. > > An HTTP/2.0 server supporting both protocol announces both like this: > > Sec-WebSocket-Extensions: ext-for-logical-ch, mux; protocol="ws, > http", ext-for-physical-conn > > ---- > > Does everything above work well when an HTTP request is the initiator? > It's often that an HTTP request precedes WebSocket connection attempt. > Actually, current WebSocket handshake + extension cannot provide clean > way path for this. > > Current bootstrap of WebSocket multiplexing allows for fallback to > non-muxed WebSocket connection without extra RTT. It's good but for > this case, we don't want to establish an unnecessary WebSocket > connection. There's no way to prevent existing non-mux capable > WebSocket servers from accepting HTTP/2.0 bootstrap by mistake. > > So for this case the differentiation between WebSocket and HTTP/2.0 > needs to be done by Upgrade type. > > GET /meaningless HTTP/1.1 > Connection: Upgrade > Upgrade: http2 > Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== > Sec-WebSocket-Extensions: mux; protocol="ws, http", > ext-for-physical-conn > > Just headers for upgrade and security are incorporated. Mux will be > established but default channel won't be opened. WebSocket servers w/o > mux support rejects this handshake. > > If over NPN, > > Sec-WebSocket-Extensions: mux; protocol="ws, http", > ext-for-physical-conn > > This is the only information to exchange. > If we think of the framing layer as separate from both Websockets and HTTP 2.0, we can look at the headers and consider which they belong to. I think the Upgrade header belongs to the framing layer. Maybe it should be "Upgrade: frames" with another header "Sec-Framing-Protocols: http2, websocket" to establish the protocols that should be carried. Who knows, perhaps eventually there will be others such as a peer-to-peer protocol between browsers. A server response could indicate which protocols it actually supported. This would not be backward compatible with the WS 1.0 handshake, but servers could support both methods fairly easily. --------------080901090905050409030104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12-07-27 01:19 AM, Takeshi Yoshino wrote:
=== First, clarify AddChannelRequest base spec ===

Let's break down headers in handshake.

  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
  Sec-WebSocket-Version: 13
  Sec-WebSocket-Extensions: ext-for-logical-ch, mux, ext-for-physical-conn

These headers (except for ext-for-logical-ch) are meaningful only when performing HTTP Upgrade and establishing physical connection.

I agree for most of these, but I am uncertain about the Sec-WebSocket-Key. The point of that (and the Sec-WebSocket-Accept) is to guarantee that both ends are actually WS endpoints. Are there not usecases where a datacenter frontend might split a muxed connection and send the channels to different servers? If so, I think we need to validate all the endpoints of channels by sending a nonce and receiving the correct hash back.

Unless people have changed their minds about the usefulness of this technique.


  GET /chat HTTP/1.1
  Sec-WebSocket-Protocol: chat, superchat
  Origin: http://example.com
  Cookie: foobar
  Sec-WebSocket-Extensions: ext-for-logical-ch
  Any-Other-Header: Its-Value

These headers determine by which virtual server / service and how the logical channel are handled. So, the initial delta encoding base should consist of only these headers.

(
It looks like moving these headers to mux's extension parameter make sense. But please note that we can't do it because of the requirement that WebSocket server w/o mux support should be able to accept the connection by just rejecting mux extension. Like this:

  HTTP/1.1 101 Switching Protocols
  ...
  Sec-WebSocket-Extensions: ext-for-logical-ch
  ...
)

Do you mean adding any number of headers as parameters to the mux extension declaration in the Sec-Websocket-Extensions header? A list of headers inside a single header seems needlessly complicated to me, even without the need for a fallback for non-muxing servers.


Response headers are also broken down into two groups. The following headers should be excluded from delta encoding base.

  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

(It's off topic but needs discussion whether we should send reply to implicitly opened channel by physical channel handshake response or we should send a separate AddChannelResponse for that. The latter allows opening mux connection even when the request for implicitly opened channel is bad e.g. 404)

IMHO the 404 should result in the connection being handled the same way it would for an HTTP XHR request. Ditto for 300 statuses where the resource might have moved to another server that requires a different connection to be established.

What if, in a particular session, there was only going to be that one channel request that had failed? A useless connection would be hanging around for no reason. If there is a second channel request that would be successful, then that can be the implicitly opened channel that establishes the mux connection.


===  Negotiation of logical channel protocol capability ===

So, how should we negotiate HTTP capability? I propose that we'll add "protocol" extension parameter. The server announces supported logical channel protocols.

WebSocket server w/o HTTP/2.0 support announces only ws (or may omit the parameter) like this:

  Sec-WebSocket-Extensions: ext-for-logical-ch, mux; protocol="ws", ext-for-physical-conn

Clients has to fall back to normal HTTP to send HTTP requests.

An HTTP/2.0 server supporting both protocol announces both like this:

  Sec-WebSocket-Extensions: ext-for-logical-ch, mux; protocol="ws, http", ext-for-physical-conn

----

Does everything above work well when an HTTP request is the initiator? It's often that an HTTP request precedes WebSocket connection attempt. Actually, current WebSocket handshake + extension cannot provide clean way path for this.

Current bootstrap of WebSocket multiplexing allows for fallback to non-muxed WebSocket connection without extra RTT. It's good but for this case, we don't want to establish an unnecessary WebSocket connection. There's no way to prevent existing non-mux capable WebSocket servers from accepting HTTP/2.0 bootstrap by mistake.

So for this case the differentiation between WebSocket and HTTP/2.0 needs to be done by Upgrade type.

  GET /meaningless HTTP/1.1
  Connection: Upgrade
  Upgrade: http2
  Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
  Sec-WebSocket-Extensions: mux; protocol="ws, http", ext-for-physical-conn

Just headers for upgrade and security are incorporated. Mux will be established but default channel won't be opened. WebSocket servers w/o mux support rejects this handshake.

If over NPN,

  Sec-WebSocket-Extensions: mux; protocol="ws, http", ext-for-physical-conn

This is the only information to exchange.


If we think of the framing layer as separate from both Websockets and HTTP 2.0, we can look at the headers and consider which they belong to.

I think the Upgrade header belongs to the framing layer. Maybe it should be "Upgrade: frames" with another header "Sec-Framing-Protocols: http2, websocket" to establish the protocols that should be carried. Who knows, perhaps eventually there will be others such as a peer-to-peer protocol between browsers.

A server response could indicate which protocols it actually supported. This would not be backward compatible with the WS 1.0 handshake, but servers could support both methods fairly easily.




--------------080901090905050409030104-- From bruce@callenish.com Tue Jul 31 06:51:31 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460A021F86EE for ; Tue, 31 Jul 2012 06:51:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-hP0Vs-8ROY for ; Tue, 31 Jul 2012 06:51:30 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.213.3]) by ietfa.amsl.com (Postfix) with ESMTP id B0E3A21F86E8 for ; Tue, 31 Jul 2012 06:51:30 -0700 (PDT) Received: from [24.108.214.86] (port=49293 helo=[192.168.145.113]) by biz82.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SwCr5-00006G-GO; Tue, 31 Jul 2012 06:51:23 -0700 Message-ID: <5017E2E8.5090005@callenish.com> Date: Tue, 31 Jul 2012 06:51:36 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Takeshi Yoshino References: <5010B103.70809@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 X-Source: X-Source-Args: X-Source-Dir: Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 13:51:31 -0000 On 7/26/2012 4:01 AM, Takeshi Yoshino wrote: > > Separating the stream identifier space into two for each direction is > necessary since each end may initiate stream asynchronously. I don't > come up with any other attribute with a risk of collision. > Not with the two protocols currently proposed, but what of the future? Will other protocols be carried on this common framing layer? If a peer to peer protocol is added then the number of endpoints that could initiate the stream is unlimited. Why can there not be a separate field to identify the endpoint that initiated the connection? > I feel that reserving ID number space is over killing. > I'm not sure what you mean by "over killing". Are you agreeing that all the bits in the ID space should serve the single purpose of defining the ID, and not be overloaded to mean other things as well?