- Added notes like "unless _Fail the Physical Connection_ is alre= ady done for any other error" so that implementors can choose flexibly= at which point they stop processing multiplex control frame with error

- Clarified that

-- minimal number of bytes MUST be used for= channel ID encoding

-- when a server received NewChannelSlot or = AddChannelResponse, it MUST fail the physical connection

-- when = a client received AddChannelRequest, it MUST fail the physical connection -- RSV bits in multiplex control blocks must be 0
-- replying to AddChan= nelRequest may be delayed
-- if fallback bit is raised in a NewChannelSl= ot, the other fields MUST be 0

Takeshi

On Thu, Sep 20, 2012 at 2:47 PM, <internet-drafts@ietf.org>= wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the BiDirectional or Server-Initiated HTTP = Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : A Multiplexing Extension for We= bSockets
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : John A. Tamplin
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Takeshi Yoshino
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-hybi-websocket-multipl= exing-06.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 41
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-09-19

Abstract:
=A0 =A0The WebSocket Protocol [RFC6455] requires a new transport connection=
=A0 =A0for every WebSocket connection. =A0This presents a scalability probl= em
=A0 =A0when many clients connect to the same server, and is made worse by =A0 =A0having multiple clients running in different tabs of the same user =A0 =A0agent. =A0This extension provides a way for separate logical WebSock= et
=A0 =A0connections to share an underlying transport connection.

=A0 =A0Please send feedback to the hybi@ie= tf.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-websocke= t-multiplexing-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-hybi-websocket-multiplexing-06

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

--e89a8f2354858b38bb04ca1bf950-- From tyoshino@google.com Sun Sep 23 21:53: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 4909021F8452 for ; Sun, 23 Sep 2012 21:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.33 X-Spam-Level: X-Spam-Status: No, score=-102.33 tagged_above=-999 required=5 tests=[AWL=0.646, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFVDo0f1wnHo for ; Sun, 23 Sep 2012 21:53:25 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B102821F8464 for ; Sun, 23 Sep 2012 21:53:25 -0700 (PDT) Received: by iec9 with SMTP id 9so10960668iec.31 for ; Sun, 23 Sep 2012 21:53:25 -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=NEiVvOCp91LLZ1X6nI7EjyDPqMhP1teUnAtcbLtpcBY=; b=mHSnbuo6lKQobDEaKMKmTVG7Kh5hPO/hsqAh1aFDt9teMb+ffCLUPewrClcw3m7n1C QYW0CxpibEZC1388yMyOOHkXs35RLMyb9hudiQIUZb2pZmCsIZB6QPLvl0D0RJugCcgR 9CXdt3dgUJcAv5AlXHg0HHXswACEf8ElKZJZCpQTQFdSt8XD7sRM+xkOkH89Zn0DsrBb j5CzDHnWpzJD1ufSUF8V1yjD60v5X2NxKJUg4VO8caZrfekGM3YbF6p4CaWPH4/I3QSJ ndyn9n3t/hFgdTiAeUT8rX6xDLJinKfJ4/fJu+zIqFtCHyjQ86KZGss0ENsYYuIJY6Pv TScA== 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=NEiVvOCp91LLZ1X6nI7EjyDPqMhP1teUnAtcbLtpcBY=; b=eEAISVeJVw3Bv4+pOhRq0gUtxovDAb6KedepIsc1WP7I4hznjC4rodZx+cZfRKWrpI bdO5W8sQCBbZXcvOzvRoT7b5vBBStQHnEBGC1GxEQE1o3QBl65mHa6DUKi/epu9ArIXb s02xsjVxKnU5hJRfqvsO6zpFRBG5v1t/fqLewtuKyGnnd+T0UP2cyD4f+zRq6smhQvpA 8JdvdMhw0p0WgLfobkW43t8CBIUXzNrFoXRj/GH7PatyiHp/iir3i5/NQkq6xHYN6Dn7 DBXZFpC7vyOoDuoPx87cv3sgm7y9LHNunRubiVjdDZtIebH7hO4T/BVzouk+e7wweS49 b1ig== Received: by 10.50.219.129 with SMTP id po1mr4182514igc.35.1348462404937; Sun, 23 Sep 2012 21:53:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.82.140 with HTTP; Sun, 23 Sep 2012 21:53:04 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Mon, 24 Sep 2012 13:53:04 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=14dae93410cba3a8ef04ca6b5eff X-System-Of-Record: true X-Gm-Message-State: ALoCoQlMOREiYAEYNRmAgvEHmy55yQhHxGaWfzj7jCG6SoCHF+303BNI4BcZT1IHXJdEu0Dn/xk+rZy2OK5iKe/PRwzw82Q3PnvTGylL2jz3owGjpaFJ2xnS66sqc0QewsbFtPTV/ksXgsDrfcOzzmellEaMD127qRuOuzzuWOLzH928FDytTsVwZdRb26Z9iliaDW5y4Ts3 Subject: Re: [hybi] Finalize flow control metric 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, 24 Sep 2012 04:53:27 -0000 --14dae93410cba3a8ef04ca6b5eff Content-Type: text/plain; charset=ISO-8859-1 Reminder. I'm going to make this change on next release of multiplexing spec unless anyone objects to it. Thanks On Thu, Aug 16, 2012 at 4:34 PM, Takeshi Yoshino wrote: > So, I suggested 1 octet (the size of encapsulated FIN, RSV1-3, opcode of > the first fragment) per message (NOT per frame) extra quota consumption in > addition to consumption equal to the length of payload. This satisfies > (a)-(d). > --14dae93410cba3a8ef04ca6b5eff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Reminder. I'm going to make this change on n= ext release of multiplexing spec unless anyone objects to it.

Thanks

On Thu, Aug 16, 2012 at 4:34 PM, Takes= hi Yoshino <tyoshino@google.com> wrote:

So, I suggested 1 octet (the size of encapsulated FIN, RSV1-3, opcode = of the first fragment) per message (NOT per frame) extra quota consumption = in addition to consumption equal to the length of payload. This satisfies (= a)-(d).

=A0

--14dae93410cba3a8ef04ca6b5eff-- From tyoshino@google.com Sun Sep 23 22:00:55 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 D3FA421F851A for ; Sun, 23 Sep 2012 22:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.431, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hoc2ctWK3zoW for ; Sun, 23 Sep 2012 22:00:53 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4EB421F8493 for ; Sun, 23 Sep 2012 22:00:52 -0700 (PDT) Received: by iec9 with SMTP id 9so10970106iec.31 for ; Sun, 23 Sep 2012 22:00:52 -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=0EncLzUpwIgz3TS1f6dOxVnAsLE2LNjef/YIuJA9qnc=; b=eXcGYa1E+Bx0yGMAwpd71fxskGpCXnTD9bJ+DjIzUcPBJnDNtbOQ7MVir1Uc5L8W2K mwcr4XnKi/qWcn1gZ8hXij01F4cxHQjqFGddo5ub+V+dKD0bAtiKLvK51Yh6ovp0qEF2 CD0iTgfVksrM8O2wxdW/7WlWIXDQNvzbU813NHjjclMF2VOWOvndGiU1usXWRSjkCfIB APAvbuPFNluTB0SBXy+fP/3tKVF0W2Gi6OWAeB7NoXQHtD+ksiZ+fBQOKGo7KS7xlv4B E/95BuXUKrpGZ/hLNTOQ9wSbDmBeeN4VYl0jnC5Jm5gH/t/P2/8hvmfpsemqeOuVfDHK 3FYw== 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=0EncLzUpwIgz3TS1f6dOxVnAsLE2LNjef/YIuJA9qnc=; b=GcyC8F1tcr6HMQEqDw3FdxtpFVH9s0tgkdyufN/rK6htGZVG5Rz5XHwQjJHjakLKxg 4lT+RL0Fr1jAG5HjHuWoBFvJEe7BxZduFglk90saTT12eMHs91kLwPh2wzPW81Jo0337 UPlkEs2gd+GgqIGXtZOUhxWCX8Du0XvcQrEH/j9PM7xmUQuDFLFLxyzI70A/34rsxnm+ kpwbWxOJQK1uqHqgUAjcgxpK4XbBQBXOtvFE+zocQMFW0Pm6aOfM/tEjsaI23n0dmkXe mjjc9IH7oQzTPu+VaDtbyN2Jw8tDtdCP1rb00qk6wMEiGpqAb22BG0uR+KKA07IAts5f P8iA== Received: by 10.50.95.231 with SMTP id dn7mr4287722igb.36.1348462852330; Sun, 23 Sep 2012 22:00:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.82.140 with HTTP; Sun, 23 Sep 2012 22:00:32 -0700 (PDT) In-Reply-To: References: <4FEA3A97.5030301@caucho.com>

From: Takeshi Yoshino Date: Mon, 24 Sep 2012 14:00:32 +0900 Message-ID: To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f2354bf4e52d504ca6b7935 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkpPbjmN9thIEq4RRj3pawCoKytT/x5Z/5biqxzByL21HihI8owzM2Oo6fiuwh0XQhgA+Fv1WT22QwXtxKgCbfhLZ3/WiFIvW0kE765tvZ3VIp2rN6gRTedMoBf29BvTBK8f/mrZE5+xn5XdhDzbS7YJQt/KHOWmyu2eeO2yarxXw5JsRbHBMmKp3tgQj1O594/5naz 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: Mon, 24 Sep 2012 05:00:55 -0000 --e89a8f2354bf4e52d504ca6b7935 Content-Type: text/plain; charset=ISO-8859-1 Hi all, For record, I'd like to state here that I'm going to postpone addition of channel ID space separation to the first release of WebSocket multiplexing specification. Discussion on extending WebSocket for HTTP/2.0 framing was not useless. WebSocket 2.0 might carry non-WebSocket traffic that needs initiation of stream from both sides. Let's take into account this idea then. We should finish WebSocket multiplexing 1.0 asap for wider adoption of WebSocket. Thanks --e89a8f2354bf4e52d504ca6b7935 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi all,

For record, I'd like to state her= e that I'm going to postpone addition of channel ID space separation to= the first release of WebSocket multiplexing specification.

Discussion on extending WebSocket for HTTP/2.0 framing was not u= seless.=A0WebSocket 2.0 might carry non-WebSocket traffic that needs initia= tion of stream from both sides. Let's take into account this idea then.= We should finish WebSocket multiplexing 1.0 asap for wider adoption of Web= Socket.

Thanks

--e89a8f2354bf4e52d504ca6b7935-- From tyoshino@google.com Mon Sep 24 08:15:33 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 3E3A821F87AA for ; Mon, 24 Sep 2012 08:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.653 X-Spam-Level: X-Spam-Status: No, score=-102.653 tagged_above=-999 required=5 tests=[AWL=0.323, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4sfFyILDepZ for ; Mon, 24 Sep 2012 08:15:32 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2653021F8798 for ; Mon, 24 Sep 2012 08:15:31 -0700 (PDT) Received: by lbok13 with SMTP id k13so1152111lbo.31 for ; Mon, 24 Sep 2012 08:15:29 -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=e2pYMAlEFuQjobFGXvLqmRbY007XY34dAxhqGLkIB9Y=; b=g/SVqyawAzmyCSFSEw//oytrHCoJ41US9WcAiIsllZWP0V+FoCwLyh6Q8iBuGndF/L nXkweC2ZORW/i5TEw/T/xYBpt/uIO8ZVhAWVlk8JxIeJF03S4vUc5EeIqQjn/QtExgu8 IghmX003x84LjY6LhfqdJaioFLHNWwPvR6kdrpiYSm1aNukR63iF1RM8ebSL/CmCXrqM xX27cVPmREaqAlQfLNs3LWXQv6U7YSHsAMwyI6bQjxPCpJRGYniz06vTcuWSFutqj1EW u/bP9mXRssPbr1qaN+VwBEiJGNVxvCmYeMbDTdfb+mzhuZ51wIcWjyGsVwMkqsYHoHMw et9g== 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=e2pYMAlEFuQjobFGXvLqmRbY007XY34dAxhqGLkIB9Y=; b=jnvMKmPruKJHxRvtzzRNO0TyqqfjLcsUgSN1zRcbcvOd29/5zUWgt434NPGl2772ID 7IsGvIBCDlGnGmd6xrcSP4NE9vzLLeCdJAPK82ij83yssO2+Y+pWIBvSDZJ84hkFajzD VKWqytfd6L1yg1UVqSZztvnQMoesGCsygUtQvENseJC/hR7ZYiZyVwhi5qtTh5YW9tJw 8aE+np7vcdaj5KwT0ILGZ7oZrNyHXtErwAPkJ0B3HIpq6rA7RYbjLtoyNdZH/BtoWKKG iZWIyhtn7YhvAYhGBTbpnsTdtuZxelyzJzFIS3mu04uBAJApUI60jRTLGeX8QSJnMOmn cxQA== Received: by 10.152.144.2 with SMTP id si2mr10990697lab.26.1348499729339; Mon, 24 Sep 2012 08:15:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.71.161 with HTTP; Mon, 24 Sep 2012 08:15:08 -0700 (PDT) From: Takeshi Yoshino Date: Tue, 25 Sep 2012 00:15:08 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=e89a8f22bfb558d48704ca740f14 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkDEaYDju2up6G++lC9zvskN2r3NU9ZyFFTqFl9DwrhurkBZhRa9Q2iteke2ZM12ExRuXARk84/IP8Tpz2tOTcyhviqm6Aa6QLODx4bwBvgNHWvKacX/79tdLQgr1xJH4jiJ1xUGK58qykLLfykjSfd+ykv6e888QharN8fiAlxRkv1xJKd1wvzT5PRYW5LyoJww1MH Subject: [hybi] [Multiplexing] Some more upcoming changes 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, 24 Sep 2012 15:15:33 -0000 --e89a8f22bfb558d48704ca740f14 Content-Type: text/plain; charset=ISO-8859-1 Hi all, About error fatalness I've added strawman texts about error handling on -04 release of the multiplexing spec. Those who are interested in the multiplexing spec, could you please take a look at them? Please post mail if you have opinions on it. http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-06#section-9.5.1 In the next draft, I'm going to move 3001, 3002, 3003, 3004 to 2XXX and make them fail the physical connection. Because we're using values in previous AddChannelRequest/Response to build the next ones, it's bad to just ignore bad ones with 3XXX DropChannel. ---- About overflow errors I've defined codes for overflow errors but they don't have corresponding texts explaining when/where they're used. My idea is: - fail the logical channel with 3006 when send quota is going to be equal to or greater than 2^63 after adding the replenished send quota in the received FlowControl. - fail the physical connection with 2008 when the number of new channel slots is going to be equal to or greater than 2^63 after adding the number of new channel slots in the received NewChannelSlot. Developers of server and UA for embedded system could live without supporting 63 bit mode length header by asking applications on them to use messages up to 2^16-1. But regarding quota and slots, the other peer (server or UA) with much CPU power and memory might send big value even if applications on them don't use big messages. So, in reality, all servers and UAs have to be able to handle value up to 2^63-1 for send quota and number of new channel slots. Is this acceptable for you? Thanks Takeshi --e89a8f22bfb558d48704ca740f14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi all,

About error fatalness

<= /div>

I've added strawman texts about error handling on -04 release= of the multiplexing spec.=A0Those who are interested in the multiplexing s= pec, could you please take a look at them? Please post mail if you have opi= nions on it.

http://tools.ietf.org/html/draft= -ietf-hybi-websocket-multiplexing-06#section-9.5.1

In the next draft, I'm going to move=A03001, = 3002,=A03003, 3004 to 2XXX and make them fail the physical connection. Beca= use we're using values in previous AddChannelRequest/Response to build = the next ones, it's bad to just ignore bad ones with 3XXX DropChannel.<= /div>

----

About overflow errors

I've defined codes for overflow errors but they d= on't have corresponding texts explaining when/where they're used.

My idea is:

- fail the logical channel with 3= 006 when send quota is going to be equal to or greater than 2^63 after addi= ng the replenished send quota in the received FlowControl.

- fail= the physical connection with 2008 when the number of new channel slots is = going to be equal to or greater than 2^63 after adding the number of new ch= annel slots in the received NewChannelSlot.

Developers of server and UA for embedded system could l= ive without supporting=A063 bit mode length header=A0by asking applications= on them to use messages up to 2^16-1.

But regardi= ng quota and slots, the other peer (server or UA) with much CPU power and m= emory might send big value even if applications on them don't use big m= essages. So, in reality, all servers and UAs have to be able to handle valu= e up to=A02^63-1 for=A0send quota and number of new channel slots.

Is this acceptable for you?

Thanks<= br clear=3D"all">Takeshi
--e89a8f22bfb558d48704ca740f14-- From tobias.oberstein@tavendo.de Wed Sep 26 15:29:35 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 637C621F8574 for ; Wed, 26 Sep 2012 15:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6139Vjp2nIW7 for ; Wed, 26 Sep 2012 15:29:35 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id DAE3121F8570 for ; Wed, 26 Sep 2012 15:29:34 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.219]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Wed, 26 Sep 2012 15:29:33 -0700 From: Tobias Oberstein To: "hybi@ietf.org" , Takeshi Yoshino Date: Wed, 26 Sep 2012 15:29:32 -0700 Thread-Topic: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-00.txt Thread-Index: Ac1/bplHTUm3CMmmQySEc7cTiRTL9gcxpSCg Message-ID: <634914A010D0B943A035D226786325D433910B6F01@EXVMBX020-12.exch020.serverdata.net> References: <20120821072123.15277.13400.idtracker@ietfa.amsl.com> In-Reply-To: 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: Re: [hybi] I-D Action: draft-ietf-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, 26 Sep 2012 22:29:35 -0000 Someone knows? Does Chrome, Firefox or any browser implement per-message compression alrea= dy, and if so beginning with which version - or is pywebsocket currently th= e only implementation on the street? Thanks, Tobias From tyoshino@google.com Wed Sep 26 17:57:29 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 5B35D21F8643 for ; Wed, 26 Sep 2012 17:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.718 X-Spam-Level: X-Spam-Status: No, score=-102.718 tagged_above=-999 required=5 tests=[AWL=0.258, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RamcNpihfcz9 for ; Wed, 26 Sep 2012 17:57:28 -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 256BA21F8634 for ; Wed, 26 Sep 2012 17:57:27 -0700 (PDT) Received: by bkcjc3 with SMTP id jc3so869822bkc.31 for ; Wed, 26 Sep 2012 17:57: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=7X35M9v6Gh6sdJG0+lcjaA+pHsqpfswUcb2YRoBDWg0=; b=T/L2FhWa16ppC7xeXJPEIK7jNVI8fFlhULpp6AJPFCAWsirok2rV6R6SqrN129lo9Z THDmAsz8lL++C0KRUO4Nh258Wyr+/kcmW2KRFZ0+ETwAk/JqKdkUfPUcAVM8V0n5dpU6 cRuqVsN6lQYLQpv2tsOnY1xU9MK+EhzmDJIK9IO3LgWQv/1wO9J65cTtk83g6/GlQSGE D6LR5KOyWFMC6u8Tm+B3jpA8MxLkk72pssJMWGtQayTXjTVTdYnNDaJb0LUkfWyqrFZf AHfpE6M5WFqLCY0PCSohrBxqyIzTi/7/0Tx1KO5YLyoL5+r3zMeX2shjMuUNBXVS43T8 +ekA== 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=7X35M9v6Gh6sdJG0+lcjaA+pHsqpfswUcb2YRoBDWg0=; b=Sqp2u9RFH+26u3XlyalHZhN21wejKCKnlDqXM4dRELwf2klwBPc8TNzyJ9GFd2sd6C GuqryU1zOQKkkJYRqDZ5knycE4Dzj5yg2C7NTkvXSjGTP2u/NEHRyX16GsCibfkSnCGt uF1sjHyVjZ4g/ZxMxTG4D33VeRgrbScRgs3RZHvrH+t/i/ujb0JOrHN98tqpejLxZ1ZR WufXngx2QKRZV6EsHl9DExdxRFBmY/Gz+BG0clC6jwyZcPwK1CkOtL7sALZW+SNR7hbB fdnaxtq+Lx6bTZCFseFoyRQNZWc6/lOoeTbelO6l8KpJh4Im0H7GDnInWj10MHEvLKVJ X/zQ== Received: by 10.112.83.170 with SMTP id r10mr1013327lby.103.1348707446951; Wed, 26 Sep 2012 17:57:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.71.161 with HTTP; Wed, 26 Sep 2012 17:57:06 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D433910B6F01@EXVMBX020-12.exch020.serverdata.net> References: <20120821072123.15277.13400.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D433910B6F01@EXVMBX020-12.exch020.serverdata.net> From: Takeshi Yoshino Date: Thu, 27 Sep 2012 09:57:06 +0900 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=f46d04016a67480d8504caa46cee X-System-Of-Record: true X-Gm-Message-State: ALoCoQmr4hXs0w2s7W25ALeQMIHK3lLP4WJGaaF/Rnp5KfzI6DSkaeujhZzC79tN1rzmM4Vg7+ky3gVx/4ao7cFfPtH/+g2fj9lyqG1t+p2YNgsMW8TU2UA1XJ8bXiD08llAAqhDCHsu01zLogXd9PW9eeenLb4jCgBy7gyIZxkkBwQHKKQMKcGflePYAQTkOFQJYBrEuYeB Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-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: Thu, 27 Sep 2012 00:57:29 -0000 --f46d04016a67480d8504caa46cee Content-Type: text/plain; charset=ISO-8859-1 Chrome: nothing is done for now. On Thu, Sep 27, 2012 at 7:29 AM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > Someone knows? > > Does Chrome, Firefox or any browser implement per-message compression > already, and if so beginning with which version - or is pywebsocket > currently the only implementation on the street? > > Thanks, > Tobias > --f46d04016a67480d8504caa46cee Content-Type: text/html; charset=ISO-8859-1 Chrome: nothing is done for now.

On Thu, Sep 27, 2012 at 7:29 AM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:

Someone knows?

Does Chrome, Firefox or any browser implement per-message compression already, and if so beginning with which version - or is pywebsocket currently the only implementation on the street?

Thanks,
Tobias

--f46d04016a67480d8504caa46cee-- From gregw@intalio.com Thu Sep 27 17:13: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 BBFD221F845F for ; Thu, 27 Sep 2012 17:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgKuR5d+S6DL for ; Thu, 27 Sep 2012 17:13:34 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EDA8E21F845D for ; Thu, 27 Sep 2012 17:13:33 -0700 (PDT) Received: by obqv19 with SMTP id v19so2870075obq.31 for ; Thu, 27 Sep 2012 17:13:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=U2Ipuc1gYps+NrdC/g2/mZWrpSdqdWQDlv4co+a5KQk=; b=g3rlP6mnpCiS2f/SUT4YVWGrUvz8Qj4j2m4kHLrclJqTshKPxJcAprWFIOy/0J6p21 iezBeid5ajnXMEeSfYrheZO0PBhNFZu4EmNoKfQhf2jDJzbgda5rSaFZ3u8Jzj5QT2bn 0T3+hn2d1YmSRXOj7iinZDd07Ikfe8Ju8t9FARxxIg9thxDso1eWfwB8ozRtpRSDz9cf n+KbY2xqUt2iWK7AxBWnkCZTrxyPniTfs1Z3yU7f9TjH/HqLgYOV6MoFpAeOJN5DWGW1 hJVxqPXDOQ4RMMKdHFjl+3eFDIhmuoeHyOBV3iK4UUlL2pWXeN+G2+8Zkghzv9CUYwnM ylDg== MIME-Version: 1.0 Received: by 10.182.145.35 with SMTP id sr3mr4464049obb.98.1348791213267; Thu, 27 Sep 2012 17:13:33 -0700 (PDT) Received: by 10.76.114.198 with HTTP; Thu, 27 Sep 2012 17:13:33 -0700 (PDT) Date: Thu, 27 Sep 2012 17:13:33 -0700 Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl+zCzGXKj5FC3f+TaaCI32t4ydEjPVE5QnWT0oimKE0whobgBMphVNj0d11IWBuBZ+w3/p Subject: [hybi] Client firewall blocks server to client messages with HTTP content 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, 28 Sep 2012 00:13:34 -0000 FYI http://stackoverflow.com/questions/12545524/message-in-jettys-websocket-connection-cannot-contain-any-http-method-keyword Perhaps we should have masked server to client traffic - I would not have thought this would occur and hence argued against it - mia culpa! So some intermediaries do need to be updated. -- Greg Wilkins http://www.webtide.com Developer advice and support from the Jetty & CometD experts. From jat@jaet.org Thu Sep 27 18:04:20 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 0A05521F8550 for ; Thu, 27 Sep 2012 18:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKwSl0a4j83h for ; Thu, 27 Sep 2012 18:04:19 -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 D7C2621F8527 for ; Thu, 27 Sep 2012 18:04:18 -0700 (PDT) Received: by bkcjc3 with SMTP id jc3so2752858bkc.31 for ; Thu, 27 Sep 2012 18:04:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=XgMM5EiLh+Lb0s0snVk3vsTiBIQ5WclBh1GeOATgsQ8=; b=H+nTckzDXUyu+lLX3RDTau2ZbmftmDkicvbPL9ljheojSJm1QpL4gHs0Jmadtn7lmy BidJoN0YrMvUazNqIpTALw9tLDQL3k7WzTMRrIdW7Btxfqn5+xreF+V7Mcy2y5036dlB XS42cPXTfCzRLoBywT75/V1jo+VdLo79HrgE3+scK+m0qj6RWPgU2fPiOjTriKeQg8TQ YNLQDjBeCoJjsQGq/JKlp73+zV//DJszjgKdg+WF7AafX5ybtVYJqqS0XMN0rnrfgsxf kK7CnnnSkkBgvER0EvkdDk2j+FWDf1QuQ5fIUzgdUYA0ugGt896e88wxUqtIljLAnLOw W/Eg== Received: by 10.204.150.209 with SMTP id z17mr3044744bkv.8.1348794257646; Thu, 27 Sep 2012 18:04:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.130.80 with HTTP; Thu, 27 Sep 2012 18:03:57 -0700 (PDT) X-Originating-IP: [198.49.103.3] In-Reply-To: References: From: "John A. Tamplin" Date: Thu, 27 Sep 2012 21:03:57 -0400 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=00151761c8fe9a240904cab8a2d4 X-Gm-Message-State: ALoCoQmgq5IJtOAzkhDxa1qBQn4PfJ4vhOXMaT/oxwJOY2T8ORW3UpknAIAA3BkRDt6gC6qWr+Sg Cc: Hybi Subject: Re: [hybi] Client firewall blocks server to client messages with HTTP content 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, 28 Sep 2012 01:04:20 -0000 --00151761c8fe9a240904cab8a2d4 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 27, 2012 at 8:13 PM, Greg Wilkins wrote: > FYI > > > http://stackoverflow.com/questions/12545524/message-in-jettys-websocket-connection-cannot-contain-any-http-method-keyword > > Perhaps we should have masked server to client traffic - I would not > have thought this would occur and hence argued against it - mia > culpa! > So some intermediaries do need to be updated. > I would still argue against it -- we shouldn't try and accommodate software that broken where it isn't a security issue involved. -- John A. Tamplin --00151761c8fe9a240904cab8a2d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 27, 2012 at 8:13 PM, Greg Wilkins <= gregw@intalio.com> wrote:

FYI

http://stackoverflow.com/questions/12545524/message-in-jettys-websocket-c= onnection-cannot-contain-any-http-method-keyword

Perhaps we should have masked server to client traffic - =C2=A0I would not<= br> have thought this would occur and hence argued against it - =C2=A0mia
culpa!
So some intermediaries do need to be updated.

I would still argue against it -- we shouldn't try and=C2=A0acco= mmodate=C2=A0software that broken where it isn't a security issue invol= ved.=C2=A0

--
John A. Tamplin
--00151761c8fe9a240904cab8a2d4-- From jamie@shareable.org Fri Sep 28 14:46:03 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 A529621F854A for ; Fri, 28 Sep 2012 14:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slMCAvfqT2f9 for ; Fri, 28 Sep 2012 14:46:02 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id 6285B21F8549 for ; Fri, 28 Sep 2012 14:46:02 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1THiNi-0006nI-LA; Fri, 28 Sep 2012 22:45:58 +0100 Date: Fri, 28 Sep 2012 22:45:58 +0100 From: Jamie Lokier To: Greg Wilkins Message-ID: <20120928214558.GD14867@jl-vm1.vm.bytemark.co.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Hybi Subject: Re: [hybi] Client firewall blocks server to client messages with HTTP content 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, 28 Sep 2012 21:46:03 -0000 Greg Wilkins wrote: > FYI > > http://stackoverflow.com/questions/12545524/message-in-jettys-websocket-connection-cannot-contain-any-http-method-keyword > > Perhaps we should have masked server to client traffic - I would not > have thought this would occur and hence argued against it - mia > culpa! > So some intermediaries do need to be updated. Masking wouldn't fix this case anyway. According to the stackoverflow page, any occurrence of "get" with any capitalisation, even as part of a longer word, trips the anti-virus. As well as other words. Being a 1:2^21 chance of that occurring in any sequence of 3 random bytes, it would occur every megabyte or so, i.e. quite often. Masking server to client traffic would just make the anti-virus block the connection seemingly at random, which is arguably worse in this instance, because it would be much more difficult to debug, and impossible to workaround by encoding the messages in the application. I wonder if the anti-virus blocks WSS (WS over TLS) when the trapped messages occur in the encrypted form? -- Jamie From gregw@intalio.com Sat Sep 29 00:23:41 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 B6BB521F84E7 for ; Sat, 29 Sep 2012 00:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRvzKa7akBhZ for ; Sat, 29 Sep 2012 00:23:40 -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 BC0D021F8446 for ; Sat, 29 Sep 2012 00:23:40 -0700 (PDT) Received: by qabj40 with SMTP id j40so440629qab.10 for ; Sat, 29 Sep 2012 00:23:40 -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=/8DwUK75fd0l7cD4xPfEPtluFOKoNINe/+rNuU+vvMY=; b=F4ezGdm31J+PAC/87A85gz/WPsoO+qO3ZjwdAxy4R2onsUC11dW5r0JUi9c3BEFoUe 5RAqLgWw6NhdGaEY729u6rg+jaLlNWkx7vsfEPpZFwu4glWEJwBeaCEbE7bs8kQUJoW+ CgaosYiXHYVVqGsXbsqD7o5buMibJfnWjxz2+6QTKZQDqTr6jLNbs3DSbQp0+ver6d/5 jFMcsVbD5A7wsNsXmnbRk6uSnbUSXtpciow3palQlkYDlIsIc7AMtYTcgs9d8zOGRiyF BibvmVqj7c2CY13tjA7q4e8wnCFftk0R5w1YnNi0gOryykQU9ozGOl4M/FUpvLjgWS39 ZevQ== MIME-Version: 1.0 Received: by 10.224.19.80 with SMTP id z16mr22382357qaa.74.1348903420007; Sat, 29 Sep 2012 00:23:40 -0700 (PDT) Received: by 10.49.50.105 with HTTP; Sat, 29 Sep 2012 00:23:39 -0700 (PDT) In-Reply-To: <20120928214558.GD14867@jl-vm1.vm.bytemark.co.uk> References: <20120928214558.GD14867@jl-vm1.vm.bytemark.co.uk> Date: Sat, 29 Sep 2012 00:23:39 -0700 Message-ID: From: Greg Wilkins To: Jamie Lokier Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmG4DSan9NTP0mV30bHZehYnOIMjTrFuVLSOZtdatIdjyvGUQ/sYF/skZwZCmL2Vl0MriNv Cc: Hybi Subject: Re: [hybi] Client firewall blocks server to client messages with HTTP content 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: Sat, 29 Sep 2012 07:23:41 -0000 On 28 September 2012 14:45, Jamie Lokier wrote: > I wonder if the anti-virus blocks WSS (WS over TLS) when the trapped > messages occur in the encrypted form? Or how it copes with XMPP chat messages like : "Don't forget to get the milk!" I guess as John says, there is no accounting for broken software - this is not a security issue just a false positive of an over zealous security check. cheers -- Greg Wilkins http://www.webtide.com Developer advice and support from the Jetty & CometD experts. From tyoshino@google.com Sun Sep 30 22:33: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 00DF921F8588 for ; Sun, 30 Sep 2012 22:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.716 X-Spam-Level: X-Spam-Status: No, score=-101.716 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWQcR8sst6i2 for ; Sun, 30 Sep 2012 22:33:10 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E45A21F84F5 for ; Sun, 30 Sep 2012 22:33:09 -0700 (PDT) Received: by iec9 with SMTP id 9so13011001iec.31 for ; Sun, 30 Sep 2012 22:33:09 -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=iJjlDx/D0KKFMgYf780uiE+O11KKCJBilbriU05WHl0=; b=J818JjUrrmKuP5rQ1vNV0raSjJHieDeByPJNUCprCpdBRWkU6ytJx1ilGj99DA+wxy 7M7PA2w78EVto2i1BsgG5G65f4ezac56JKivFy21ylifLVdsJzjsFp3Hi78zzggb9jCy 0ixp0rFRfcNqhFVh8JiMtJ+hhUmpF3WZIAKWEM3rtfJeigfjssvH9Jk9quyHBhS/TpWv WFqCRaJ88VQwJ9jQpegQosXk66/JtaiAPqP4gfOD4J/VxZXRiqI6fqswBZFSvAkoL3tX j16D8sQuqn1KMnC/rIpLobVk4HarQJFFuMxdFmT+KzWg3ho63R4et0Ano+amnbP60+/t A1mA== 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=iJjlDx/D0KKFMgYf780uiE+O11KKCJBilbriU05WHl0=; b=AdJsFS64HPclsLSMhuyJ1KaCaf1liUKO1AnWu+7CF+d9worY55St6xxS/LBl/hRSzF Xqa2wNj8gi4THeCT+77yB1q7DX853ge1ibuQbn92C5glsYHaL8nWYO8gn+0/Mew4REc7 wb5xOfMVajPaqeJ1ZJXUBRUjALTRCaA43iG59ZgE74QyMk6Z7RlQ7aEHSlZ+DLg66vJt pj8UpXhHWOAMgqHPPHGGySFcS/V5Cmj8B2VY9CTBY3BYaktYgrw5LNYUKwNjrIMGNxsW QZ/IVSC0HO7eJ8dJIP7d20P8V+PlCpTgk7YH+/bkaWrqo6ECpIFsJsby+Qhco6bZB40+ 1KtA== Received: by 10.50.237.69 with SMTP id va5mr4666373igc.55.1349069589340; Sun, 30 Sep 2012 22:33:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.82.140 with HTTP; Sun, 30 Sep 2012 22:32:49 -0700 (PDT) From: Takeshi Yoshino Date: Mon, 1 Oct 2012 14:32:49 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=14dae93409a5a6628904caf8bdf2 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkqSCb0JCHahNi8ASxbVX4CMyFmRLXSv/czgE2hnscnFRqUMTYT6oMJ6VUt+JyVRwVPGs3a0qekTJLJQOTXoGcLkJKyg79OT3kXL/bcLtegKZDWIJj3t81l5FS4dSlzfv2lLkCN5gLCWlmVhpcks6UhePydJlUcz7picZiEF/2Mu57GKiwxL9KtlgflMQyKxX9xmcIN Subject: [hybi] "Cache-Control: no-cache" may improve handshake success rate 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, 01 Oct 2012 05:33:11 -0000 --14dae93409a5a6628904caf8bdf2 Content-Type: text/plain; charset=ISO-8859-1 It seems adding the Cache-Control header to the WebSocket handshake improves success rate for some environment. We've investigated one bug report [1] for Chrome, and found that there're some caches deployed in Thailand which corrupt server's opening handshakes by replacing the value in the Connection header with close. This doesn't happen if Firefox is used. Some tests using reduced header set indicated that it's because Firefox puts the Cache-Control and Pragma header like this: Pragma: no-cache Cache-Control: no-cache in its WebSocket client's handshakes while Chrome does not send such headers. I guess that the proxy is caching server's opening handshake and sending the cached data but after overwriting the Connection header ignoring the meaning of "Connection: Upgrade". Basically, we want Upgrade non-compliant proxies to be replaced with new ones rather than taking work around, but don't have much reluctance to use of the headers. ---- [1] http://code.google.com/p/chromium/issues/detail?id=148908. Thanks bangkokmaco. --14dae93409a5a6628904caf8bdf2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

It seems adding the Cache-Control header to the WebSocket handshake im= proves success rate for some environment.

We'v= e investigated one bug report [1] for Chrome, and found that there're s= ome caches deployed in Thailand which corrupt server's opening handshak= es by replacing the value in the Connection header with close.

This doesn't happen if Firefox is used. Some tests = using reduced header set indicated that it's because Firefox puts the C= ache-Control and Pragma header like this:

Pragma: no-cache

Cache-Control: no-cache

in its WebSocket client's handshakes wh= ile Chrome does not send such headers.

I guess tha= t the proxy is caching server's opening handshake and sending the cache= d data but after overwriting the Connection header ignoring the meaning of = "Connection: Upgrade".

Basically, we want Upgrade non-compliant proxies to be = replaced with new ones rather than taking work around, but don't have m= uch reluctance to use of the headers.

----

[1] http://code.google.com/p/chromium/issues/detail?id=3D1= 48908 .=A0Thanks=A0bangkokmaco.

--14dae93409a5a6628904caf8bdf2--