Re: [hybi] #1: HTTP Compliance

Greg Wilkins <gregw@webtide.com> Thu, 22 July 2010 00:43 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 126D83A6987 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 17:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level:
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osipn-fCb0k7 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 17:43:31 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B29163A68F5 for <hybi@ietf.org>; Wed, 21 Jul 2010 17:43:30 -0700 (PDT)
Received: by fxm1 with SMTP id 1so4372894fxm.31 for <hybi@ietf.org>; Wed, 21 Jul 2010 17:43:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.122.148 with SMTP id l20mr1073376far.84.1279759426875; Wed, 21 Jul 2010 17:43:46 -0700 (PDT)
Received: by 10.223.112.129 with HTTP; Wed, 21 Jul 2010 17:43:46 -0700 (PDT)
In-Reply-To: <20100722001105.GH14589@shareable.org>
References: <4BF12FF1.2020101@webtide.com> <15307.1274106895.116423@Sputnik> <Pine.LNX.4.64.1005172259030.22838@ps20323.dreamhostps.com> <20100518003753.GP20356@shareable.org> <Pine.LNX.4.64.1005180229430.22838@ps20323.dreamhostps.com> <20100518121245.GR20356@shareable.org> <AANLkTiniCjBwm5T59as8jByM5xDhPMrea-GqZFpWPAVS@mail.gmail.com> <Pine.LNX.4.64.1005182105360.22838@ps20323.dreamhostps.com> <AANLkTingZLsWoejLWbEbXGy_9mBo4eBc_Kv0wW9_Q0Xr@mail.gmail.com> <AANLkTild4QZdIO56pvt7vPAC2LFb59cHy7QUsEWauzK4@mail.gmail.com> <20100722001105.GH14589@shareable.org>
Date: Thu, 22 Jul 2010 10:43:46 +1000
Message-ID: <AANLkTineDSyKlj9lng4Qm3MTX2j3Z0NdF16ULHQo-9HX@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: Jamie Lokier <jamie@shareable.org>
Content-Type: multipart/alternative; boundary="001636c5a4a609732d048bef36f6"
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] #1: HTTP Compliance
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: Thu, 22 Jul 2010 00:43:32 -0000

On 22 July 2010 10:11, Jamie Lokier <jamie@shareable.org> wrote:

> Greg Wilkins wrote:
> >    I can visibly tell when establishing a
> >    chat room if I have the WS transport enabled in the client or not,
> >    because I can see the extra delays as WS is tried and fails.
> >    This will be a barrier to frameworks like cometd-2 including WS in
> >    their transport negotiations.
>
> (Aside: I think Ian's past responses suggest the following resolution:
> When you're establishing a chat room connection, you *ought* to know
> if you're connecting to a WS-aware chat service, in the same way that
> you already must know in advance which WS subprotocol to request
> if you do get a WS connection.)
>
>
Jamie,

I'm afraid that the "knowledge" based resolution does not work in practise.

The server side of a webapplication can know if websocket is support on the
server, but it cannot know if is supported in the network infrastructure for
a particular deployment and/or client.

Even if the server side does know, it is the client that needs that
knowledge.   So the initial javascript loaded by the client could be
dynamically generated to indicate if websocket is supported or not - but
that would mean the js could not be cacheable (which has it's own
problems).   Alternately an Ajax request could be made by the client to the
server to ask if websocket is supported... but that is another round trip
and is essentially "handshaking" to see if it is permissible to handshake,
which then still might fail because of an intermediary unknown to both
client and server.

The simplest solution is for the client side frame work to check if
websocket is supported in the browser, and if so attempt to establish a
websocket connection to the server, which will test the infrastructure, the
server and the current server side application configuration in a single
request.  If that fails, it would be ideal if the TCP/IP and TLS session
negotiated could then be reused for subsequent HTTP based transports.

cheers