Re: [hybi] Websocket success rates and TLS extension.

Greg Wilkins <gregw@webtide.com> Sat, 17 April 2010 08:38 UTC

Return-Path: <gregw@webtide.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9EDE3A6965 for <hybi@core3.amsl.com>; Sat, 17 Apr 2010 01:38:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.689
X-Spam-Level:
X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lah9kHJbuIhY for <hybi@core3.amsl.com>; Sat, 17 Apr 2010 01:38:19 -0700 (PDT)
Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id C2CB93A6802 for <hybi@ietf.org>; Sat, 17 Apr 2010 01:38:18 -0700 (PDT)
Received: by bwz25 with SMTP id 25so3875653bwz.28 for <hybi@ietf.org>; Sat, 17 Apr 2010 01:38:06 -0700 (PDT)
Received: by 10.204.11.18 with SMTP id r18mr2622293bkr.55.1271493486512; Sat, 17 Apr 2010 01:38:06 -0700 (PDT)
Received: from [192.168.0.100] (host116-234-static.43-88-b.business.telecomitalia.it [88.43.234.116]) by mx.google.com with ESMTPS id 14sm2238603bwz.2.2010.04.17.01.38.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 17 Apr 2010 01:38:06 -0700 (PDT)
Message-ID: <4BC9736B.3030704@webtide.com>
Date: Sat, 17 Apr 2010 10:38:03 +0200
From: Greg Wilkins <gregw@webtide.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
References: <4BBAECB7.2030009@webtide.com> <n2j5c902b9e1004170045if1df8e7atf67f926c1452996@mail.gmail.com> <4BC96F43.3030806@webtide.com> <4BC971F7.5030605@gmx.de>
In-Reply-To: <4BC971F7.5030605@gmx.de>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Websocket success rates and TLS extension.
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Apr 2010 08:38:20 -0000

Julian Reschke wrote:
> On 17.04.2010 10:20, Greg Wilkins wrote:
>> ...
>> The other idea I had on a similar RTT would be to allow the
>> 101 response for an upgrade to contain a body.
>>
>> This a browser could send
>>
>>     GET /somethingUseful/andThenUpgrade
>>     Upgrade: WebSocket
>>
>> and the response would return a useful entity, thus not wasting
>> a RT, and then upgrade after the response body.
>>
>> Unfortunately I think this goes beyond the charter of
>> the current HTTPbis working group.
>> ...
> 
> 1xx messages only come with headers, right.
> 
> But then, can't you just put the payload into a new response header?

Indeed!  it could even be the very first frame sent out over
the websocket connection.

So if the user was a SPDY/BWTP like sub protocol over
websocket, then the conversation could go something like:


>  GET /somethingUseful
   Upgrade: Websocket

<                  HTTP/1.1 101 Switching Protocols

<                  0x00 frame containing HTTP response
                        and something useful 0xff

>  0x00 frame containing next HTTP request 0xFF
>  0x00 frame containing next next HTTP request 0xFF
<                  0x00 next HTTP response 0xFF
<                  0x00 next next HTTP response 0xFF

etc.

That solves the non TLS RTT issue pretty well I think!

cheers