Re: [hybi] Web sockets and existing HTTP stacks

Mark Nottingham <mnot@mnot.net> Mon, 01 February 2010 09:57 UTC

Return-Path: <mnot@mnot.net>
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 A645228C161 for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 01:57:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.909
X-Spam-Level:
X-Spam-Status: No, score=-4.909 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, GB_I_INVITATION=-2]
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 0dQK6FTx8iEa for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 01:57:39 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 2B7E828C15F for <hybi@ietf.org>; Mon, 1 Feb 2010 01:57:38 -0800 (PST)
Received: from chancetrain-lm.mnot.net (unknown [118.209.167.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0C81122E1F3; Mon, 1 Feb 2010 04:58:04 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <ad99d8ce1001312340y1056d7f6w2c570bdbb724edb1@mail.gmail.com>
Date: Mon, 01 Feb 2010 20:58:01 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5A8D0931-23AA-4006-B49C-65F3244B76A1@mnot.net>
References: <557ae280911171402v7546e5e7n93a1e57f87dc10e5@mail.gmail.com> <Pine.LNX.4.62.0912032347360.15540@hixie.dreamhostps.com> <4B2C1D52.9020505@webtide.com> <5c902b9e0912181640n497169cdrfa71f9a2908e6ef3@mail.gmail.com> <20091219005442.GA10949@shareable.org> <4B2C287E.1030006@webtide.com> <Pine.LNX.4.64.1001310835410.3846@ps20323.dreamhostps.com> <5821ea241001311219j111d25a3h27fb2d05a2ece32d@mail.gmail.com> <20100201012914.GC20940@shareable.org> <470737.82505.qm@web95410.mail.in2.yahoo.com> <ad99d8ce1001312340y1056d7f6w2c570bdbb724edb1@mail.gmail.com>
To: Roberto Peon <fenix@google.com>
X-Mailer: Apple Mail (2.1077)
Cc: hybi@ietf.org
Subject: Re: [hybi] Web sockets and existing HTTP stacks
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: Mon, 01 Feb 2010 09:57:40 -0000

Indeed. HTTP is *designed* to allow upgrades to other protocols. If anyone wants to argue against that, they're more than welcome to come argue that in HTTPbis, although I have a feeling they'll be needing an asbestos suit...

From this perspective, the only issue I* have with WebSockets is how it constrains the initial interchange to a subset of full HTTP; this may cause problems with some HTTP implementations (e.g. a server stack that wants to parse the request with an existing library before handing it off to the WebSockets code, where it doesn't provide enough fidelity in its abstractions). That's easily fixed.

Cheers,

* and, AFAICT, most of the HTTP community. YMMV.



On 01/02/2010, at 6:40 PM, Roberto Peon wrote:

> I am a server developer
> I do expect that if something goes over port 80, it should conform to HTTP spec until the spec agrees that it no longer applies.
> We have a significant and large population of users who have no understanding of the underpinnings of the technology-- all they want is their web pages to work. 
> 
> If you're seriously saying that we should not acknowledge that the web is broken over anything other than port 443 (heck, I don't even think that you can claim that port 80 works all the time, especially if you want to use UPGRADE, etc.), I'm interested in hearing about hard data that supports that assertion.
> 
> In other words, If deployment using a new port isn't a problem, what is the solution? Whatever it is, should it exist, I'd be happy to use it. 
> -=R
> 
> On Sun, Jan 31, 2010 at 10:32 PM, Mridul Muralidharan <mridulm80@yahoo.com> wrote:
> ----- Original Message ----
> 
> > From: Jamie Lokier <jamie@shareable.org>
> > To: Pieter Hintjens <ph@imatix.com>
> > Cc: hybi@ietf.org
> > Sent: Mon, 1 February, 2010 6:59:14 AM
> > Subject: Re: [hybi] Web sockets and existing HTTP stacks
> >
> > Pieter Hintjens wrote:
> > > On Sun, Jan 31, 2010 at 10:22 AM, Ian Hickson wrote:
> > >
> > > > Well, yeah. That's going to be the case with any protocol that shares its
> > > > port with HTTP. Web Socket tries to make this easier by making it at least
> > > > _possible_ to parse the header with an HTTP stack, if not necessarily
> > > > easy.
> > >
> > > Do you not understand the impact of breaking (cheerfully or not) a
> > > 30-year standard respected by the entire Internet?
> > >
> > > Post 80 is not shared by protocols.  Port 80 IS HTTP by definition, by
> > > contract.
> >
> > It is a fact that internet access is only granted over ports 80
> > and/or 443 at some locations.
> >
> > This is why WebSocket uses those.  It is for that practical reason,
> > not from a desire to break the port convention.  Thus there is no
> > point complaining on port convention grounds.
> 
> 
> This is an oft-repeated argument in this list, and in some xmlrpc/WS lists - and I am not very sure I buy the argument.
> There is a reason why only http is allowed by a lot of firewalls and proxies - and it is a deployment choice the customer makes : whether driven by security concerns, convention, or other - it is a conscious decision at times (not always, I admit).
> 
> At times? What percentage of web users out there know how it all works? .. and driven by "convention" is a poor reason to do something.
> 
> 
> 
> The reasoning that - port 80 is not blocked, so let us tunnel protocol xyz over it, is not a very good line of reasoning: it is not an invitation for protocol designers to tunnel arbitrary protocols on top of http.
> Either you send http on top of port 80, or use something else - so that a deployment has control : both in terms of security concerns, intermediaries which can be deployed, contractual validation, etc.
> 
> All of those things can still do the right thing over port 80. They see what they don't like, then they can drop it.
> .. and much of the difficulty in deploying anything "new" on the web today is because of intermediaries that the user doesn't know exist (and thus couldn't desire the presence of..)
> 
> -=R
> 
> 
> My 2 cents.
> Regards,
> Mridul
> 
> 
> >
> > An earlier version of WebSocket proposed port 81, but that was changed to 80.
> >
> > I do wonder if those sites only allowing port 80 all run intercepting
> > proxies on port 80 which would prevent WebSocket using it, so that it might
> > as well use port 81 anyway. Anybody know?
> >
> > -- Jamie
> > _______________________________________________
> > hybi mailing list
> > hybi@ietf.org
> > https://www.ietf.org/mailman/listinfo/hybi
> 
> 
> 
>      Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi


--
Mark Nottingham     http://www.mnot.net/