Re: [hybi] #1: HTTP Compliance

Jamie Lokier <jamie@shareable.org> Wed, 21 July 2010 23:36 UTC

Return-Path: <jamie@shareable.org>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909643A6824 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 16:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.463
X-Spam-Level:
X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 aE3LGa2L6kYt for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 16:36:51 -0700 (PDT)
Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 6F91F3A6809 for <hybi@ietf.org>; Wed, 21 Jul 2010 16:36:51 -0700 (PDT)
Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from <jamie@shareable.org>) id 1ObiqY-0000tr-2A; Thu, 22 Jul 2010 00:37:06 +0100
Date: Thu, 22 Jul 2010 00:37:06 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Roberto Peon <fenix@google.com>
Message-ID: <20100721233706.GF14589@shareable.org>
References: <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> <20100519013238.GB2318@shareable.org> <Pine.LNX.4.64.1007210108300.7242@ps20323.dreamhostps.com> <AANLkTinN=f5tOur+GN9KQF+z90iNDSTH1wGgxPk1Gh8k@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <AANLkTinN=f5tOur+GN9KQF+z90iNDSTH1wGgxPk1Gh8k@mail.gmail.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
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: Wed, 21 Jul 2010 23:36:52 -0000

Roberto Peon wrote:
> 
>    On Tue, Jul 20, 2010 at 11:47 PM, Ian Hickson <[1]ian@hixie.ch> wrote:
> 
>    On Wed, 19 May 2010, Jamie Lokier wrote:
>    > >
>    > > If we want to support multiple subprotocols at once, we can do so
>    > > quite easily by just making the subprotocol list be
>    comma-separated.
>    > > Would this be a good idea?
>    >
>    > I think it is a good idea, although there is a risk of low-quality
>    > server but significant implementations matching a literal string,
>    > breaking when other values are added to the comma-separate list, and
>    > therefore making it impossible for clients to actually use the
>    > capability.
> 
>      Yeah, though since that bug would be specific to implementations of
>      particular subprotocols, it would be pretty localised to individual
>      communities. That's probably an acceptable problem.

Fwiw, this has happened before in generic HTTP clients, including some
major browsers, so it wasn't localised to particular communities.  I
guess requiring "Connection: close" to be literally that without
anything else on the line has gone away now :-) But I'm still not sure
if there are HTTP clients/servers in use which would match
",somekeyword," inside a quoted string in a HTTP header where such
things aren't meant to be matched...

>    > But assuming the comma-separated list did catch on, a consequence of
>    > that would be the "below the API" part of WebSocket would have a
>    place
>    > to add its own distinct entries to the comma-separated list, for
>    > recognition by the other side as transport option requests (such as
>    > compression, etc.), safe in the knowledge it wouldn't break
>    negotiation.
>    >
>    > (Separate headers would be much cleaner for that, though).
> 
>      I don't see why we wouldn't just use separate fields for that. No
>      need to overload the subprotocol field.

It cannot use the subprotocol field if the *current* spec gets
significantly deployed, because the client Javascript sets the
subprotocol field, and the server is entitled to expect to get
*exactly* what the client Javascript sets.

That means WebSocket client implementations cannot transparently
append comma-separated keywords to the subprotocol field without
breaking expectations.

I really hope we sort out feature negotation before there's any
significant deployment.

We should also keep in mind that "below the API" isn't always going to
be a clear line.  Some protocol features may be implementable above or
below the Javascript API, according to client capabilities, and some
might be implemented in a WS-aware proxy away from the browser (for
example keepalive modifications when crossing between different
network types).

-- Jamie