Re: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies

Roberto Peon <fenix@google.com> Wed, 07 July 2010 05:13 UTC

Return-Path: <fenix@google.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 3D7983A6858 for <hybi@core3.amsl.com>; Tue, 6 Jul 2010 22:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.976
X-Spam-Level:
X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 db3AC+3XrVES for <hybi@core3.amsl.com>; Tue, 6 Jul 2010 22:13:15 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 47A8F3A683C for <hybi@ietf.org>; Tue, 6 Jul 2010 22:13:15 -0700 (PDT)
Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o675DGLO024201 for <hybi@ietf.org>; Tue, 6 Jul 2010 22:13:17 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278479597; bh=NkzlzLNmCPM7OR9asbIHZHlxWis=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=hr7YpDNUgv8miGEKDErhWEiIF3C2L3Wz1tnEHvJEAvAmx1cLx77K2G3qwl8cqbnVN EZbQ7RtAHvAbZv8HN8ndg==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=k/viFTHgsSPYTkfSl6YXoqEbaN/6yqflbkTIsR8rue27KDCRTCriPfyhEifxMRx09 XwZqQDQu20vn/cU9H1U/w==
Received: from gxk28 (gxk28.prod.google.com [10.202.11.28]) by wpaz24.hot.corp.google.com with ESMTP id o675DF3M015137 for <hybi@ietf.org>; Tue, 6 Jul 2010 22:13:15 -0700
Received: by gxk28 with SMTP id 28so1783294gxk.40 for <hybi@ietf.org>; Tue, 06 Jul 2010 22:13:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.82.9 with SMTP id f9mr3316215agb.124.1278479595430; Tue, 06 Jul 2010 22:13:15 -0700 (PDT)
Received: by 10.150.66.12 with HTTP; Tue, 6 Jul 2010 22:13:15 -0700 (PDT)
In-Reply-To: <20100707044129.GH12126@1wt.eu>
References: <20100706210039.GA12167@1wt.eu> <B709B846-2A8C-4B84-8F4D-B06B81D91A7B@brandedcode.com> <20100707044129.GH12126@1wt.eu>
Date: Tue, 6 Jul 2010 22:13:15 -0700
Message-ID: <AANLkTik-i_9a7JpaFRqPLBr68buPM5Ml3N1iabaJby8k@mail.gmail.com>
From: Roberto Peon <fenix@google.com>
To: Willy Tarreau <w@1wt.eu>
Content-Type: multipart/alternative; boundary=001636163fb7236edf048ac53a3a
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies
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, 07 Jul 2010 05:13:31 -0000

On Tue, Jul 6, 2010 at 9:41 PM, Willy Tarreau <w@1wt.eu>; wrote:

> On Wed, Jul 07, 2010 at 12:44:32PM +1000, Micheil Smith wrote:
> > Willy,
> >
> > Thanks for raising this point. I'm an author of a node.js powered
> websocket
> > server, and this was actually a really awkward part of the websocket spec
> to
> > comply to when writing my server.
> >
> > Without having a content-length header, the http parser in node doesn't
> know
> > how to handle the extra data it receives in that initial handshake. What
> we
> > ended up doing as a fix, was just to provide an upgradeHead as a slice of
> the
> > buffer from where the headers ended to the end of the packet.
> >
> > In short, I'd be all for having a content-length header sent to declare
> the body
> > as a body, or to declare it as just extra data that should be handled
> post upgrade.
> > >From what I can tell from what Ian is telling me over irc, he'd be more
> inclined to
> > add in content-length: 0 as a header, then content-length: 8.
> >
> > Hopefully this reply does make somewhat sense.
>
> Content-length: 0 also makes sense but it means that the nonce will
> be sent *after* the handshake, which means we'd have a second
> round-trip. For some sites who deal with hundreds of thousands of
> concurrent connections (and I know some), having two more packets
> in a connectionn is an unneeded increase of network traffic. For
> this reason, I think that the idea of the nonce in the request header
> is good.
>
>
If we're worried about hundreds of thousands of connections, then we need
multiplexing of sessions over one TCP connection between the browser and the
server.
I, for one, am extremely worried about it, and am perhaps more worried that
many seem to be just shrugging it off-- even ignoring the server scalability
problems, NAT boxes do really funny and nasty things when their connection
tables overflow.


I do love that we're thinking about ways to make fail-fast happen within the
context of HTTP. This makes so much more sense to me.
-=R


> However, I think that having content-length: 0 in the *response* will
> definitely help eliminating incompatible intermediates : those who
> properly support 101 will forward the data regardless of the content
> length because the tunnel is established. Those who don't completely
> support 101 will stop at the content-length and not forward the
> response. Alternatively, it might be nice to use a transfer-encoding:
> chunked in the response with only an end of chunk ("0\r\n") before the
> nonce. That would permit the client to check if it receives only the
> "0\r\n" or if it receives the nonce too. An increased check could also
> consist in setting "Connection: close" in the response in addition with
> the transfer-encoding or content-length. That way, incompatible
> intermediates won't remain open waiting for anything and will quickly
> close the connection before the part they don't support.
>
> Regards,
> Willy
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>