Re: multiplexing -- don't do it
Mike Belshe <mike@belshe.com> Wed, 04 April 2012 00:20 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CF521F8567 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 3 Apr 2012 17:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.693
X-Spam-Level:
X-Spam-Status: No, score=-9.693 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoanG89I1vaD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 3 Apr 2012 17:20:43 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id DA2DF21F8564 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 3 Apr 2012 17:20:37 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SFDx8-0008E4-Oq for ietf-http-wg-dist@listhub.w3.org; Wed, 04 Apr 2012 00:19:58 +0000
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <mike@belshe.com>) id 1SFDx1-0008Cu-35 for ietf-http-wg@listhub.w3.org; Wed, 04 Apr 2012 00:19:51 +0000
Received: from mail-iy0-f171.google.com ([209.85.210.171]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <mike@belshe.com>) id 1SFDwx-0006I9-LR for ietf-http-wg@w3.org; Wed, 04 Apr 2012 00:19:49 +0000
Received: by iadj38 with SMTP id j38so479168iad.2 for <ietf-http-wg@w3.org>; Tue, 03 Apr 2012 17:19:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=NRktxt5r920ymIVafhhTR0STQEpWu+USNisAT8+J9Us=; b=Wtk+iu2nIw+MH0iVoTXPJgSuCl0UBtx3CkgIGO10mjmhUJNT21NcIT7bTpXT8VgdFe Y4i2VZg17MZjkYyEyH2ovS4YIkhJCAgbZRYuI84zAwmZB6zS75nxD8XOzJtz1qssbCgs fDRNkSV5+hnX1AhVxF7CNhJvTnQzcEi4y8Tt5VeNBKI0d2ayEka7UB6aAgYMo0/CpYaj 2KlLqZmEAtt+eYl0+T/BO/UNoNCnhaPQEJkh8UMPIJx0NlOQfnQ85rcjPDN+8VguRmoO tBJOpuaRL0+r73ijCNt2VmYNsZHDC9QAADbuVK1GKpE4a+q6djmyo9Q6dhx1VGCkV0Kf dtsw==
MIME-Version: 1.0
Received: by 10.50.95.167 with SMTP id dl7mr99560igb.6.1333498762461; Tue, 03 Apr 2012 17:19:22 -0700 (PDT)
Received: by 10.50.91.162 with HTTP; Tue, 3 Apr 2012 17:19:22 -0700 (PDT)
In-Reply-To: <A4080B50-60F0-4EF5-A437-416EB4E72232@gbiv.com>
References: <4F763DD2.70604@isode.com> <em3e102790-aa55-4d0f-9ff3-39bf0ca77fd3@boist> <CABaLYCvGt=pqwVXaWMMUTyD1Gg=qizRG_WuekC33awBRu53AAQ@mail.gmail.com> <4F76AABF.3010201@gmx.de> <CABaLYCsB+outivXFwj8iFH+dM6XedxwR672Rw7pOhtzj7r6X-A@mail.gmail.com> <A4080B50-60F0-4EF5-A437-416EB4E72232@gbiv.com>
Date: Tue, 03 Apr 2012 17:19:22 -0700
Message-ID: <CABaLYCsvWkLJ0JVwdNY13HMxnvftZ1sEyhHuJEdRM2PAf=N=Tw@mail.gmail.com>
From: Mike Belshe <mike@belshe.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="e89a8f3ba0ad0b7fca04bccf600f"
X-Gm-Message-State: ALoCoQnin2ISImpcloqfcPjD3KBeGh3RkRmJ7ineqf/LfaXODonNLyk/k9fYrX6FbKki0s0Lep2M
Received-SPF: none client-ip=209.85.210.171; envelope-from=mike@belshe.com; helo=mail-iy0-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7
X-W3C-Scan-Sig: lisa.w3.org 1SFDwx-0006I9-LR c24615d2e7ef176a3c18646394203f56
X-Original-To: ietf-http-wg@w3.org
Subject: Re: multiplexing -- don't do it
Archived-At: <http://www.w3.org/mid/CABaLYCsvWkLJ0JVwdNY13HMxnvftZ1sEyhHuJEdRM2PAf=N=Tw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/13282
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1SFDx8-0008E4-Oq@frink.w3.org>
Resent-Date: Wed, 04 Apr 2012 00:19:58 +0000
On Tue, Apr 3, 2012 at 3:23 PM, Roy T. Fielding <fielding@gbiv.com> wrote: > On Mar 31, 2012, at 4:11 AM, Mike Belshe wrote: > > On Sat, Mar 31, 2012 at 8:57 AM, Julian Reschke <julian.reschke@gmx.de>wrote: > >> On 2012-03-31 01:53, Mike Belshe wrote: >> >>> ... >>> >>> Before thinking this way we should look at how well other mandatory but >>> optional to use features have turned out. >>> >>> One such example is pipelining. Mandatory for a decade, but optional to >>> implement. We still can't turn it on. >>> ... >>> >> >> But then many people have it turned on, and it seems to be on by default >> in Safari mobile. Maybe the situation is much better than you think. >> > > The data is overwhelming that it doesn't work. > > > It works just fine. The data shows only that a general-purpose browser, > that doesn't even bother to report the nature of network protocol errors, > encounters a small percentage of network problems that exceed its users' > tolerance for failure conditions because its users have no control over > their network. That might indicate that the browser cannot deploy it, or > it might indicate that there was a protocol bug on the browser that failed > on edge cases (just like Netscape 1-3 had a buffer reading bug that would > only trigger if the blank line CRLF occurred on a 256 byte buffer > boundary). > > It doesn't indicate anything about whether the feature works in HTTP for > clients that are not browsers or for networks where the administrators > do control their own deployment of intermediaries. > If you've got data that shows differently, I'm happy to view it. But, to dismiss the only data we have measured right now doesn't seem prudent? I would very much like to have data from multiple vendors on this issue, however. > > Data points: > a) chrome study showing connectivity results on port 80, 443, and 61xxx > for websockets showed >10% failures on port 80 for non HTTP protocols. > > > Unrelated to pipelining. > Very related to the deployability of new protocols over port 80. > > b) no major browser has deployed pipelining. It's not like we don't want > to. We all want to! Ask Patrick McManus for details - to think this works > is just wishful thinking. If all we had to do was turn on pipelining 3 > years ago, we would have done it. > > > Major browsers care about all networks and all customers. Most of the > clients > on the Web are not major browsers. Most of the systems on the Web that > use HTTP > pipelining deploy it within environments wherein they do control the > network > and can rubbish the stupid intermediaries that fail to implement it > correctly. > The rest can and do tolerate 5% failure rates because they actually report > errors to the user and then the user fixes their own network problem. > I thought a requirement of HTTP/2.0 is that we could deploy it on major browsers on the Internet - is that not a requirement? > > For the record - nobody wants to avoid using port 80 for new protocols. > I'd love to! There is no religious reason that we don't - its just that > we know, for a fact, that we can't do it without subjecting a non-trivial > number of users to hangs, data corruption, and other errors. You might > think its ok for someone else's browser to throw reliability out the > window, but nobody at Microsoft, Google, or Mozilla has been willing to do > that... > > As for mobile safari - I mentioned this in my talk the other day - its a > bit of a conundrum. Android's browser (not chrome) also turns on > pipelining. But I know that neither Apple nor the Android team have > produced data or analyzed the success or failures of pipelining. Mobile > browsing is downright awful (due to bad content, networking errors, and > other things). It could be that mobile networks have fewer interfering > proxies, or it could be that these errors are just getting blamed on other > mobile network glitches. I honestly don't know. I'd love to see data on > the matter. > > > Mobile networks use proxies that are owned by the mobile network. > That is why they can and do implement pipelining. > You're speculating, right? How do you know that mobile networks don't have pipelining problems? Have you measured? > > We have to realize that HTTP is used everywhere. The problems you > have encountered while writing a general-purpose browser are not the > same problems that I encounter while writing a spider and a content > management system, what Samsung encounters when writing a TV and a > refrigerator, what Willy encounters while writing a proxy, etc. > There is no universal set of features for HTTP. > Dedicated networks may have different properties. But anyone using HTTP over the general internet will likely run into similar problems that browsers do. I thought we wanted this to work over the Internet? > > I have seen dozens of systems over the years deploy products that are > entirely dependent on chunked requests and never see a single problem > with them because they are interacting with an Apache module that uses > the chunked parser that I wrote. They don't give a rat's ass about your > experience with a general-purpose browser making use of general Internet > access without any control over the intermediaries. That is not a problem > they share. > > They still need a standard for HTTP that includes the features they use. > > Either way - until someone produces data to contradict the current major > browser data - we need to stop dreaming that port 80 is viable for anything > other than pure HTTP. The data we have says its not. > > > You must be thinking of some other thread. An exchange over port 80 will > either work or it will not -- the trick is to design the protocol so that > it can succeed, or fails in a safe and recognizable way. > > Either produce new data or admit you don't know and trust what the browser > developers are telling you. > > > Hah! That's a good one. > I'm really asking for help here; I'd love to see more data. > > Regardless, I consider some form of multiplexing to be a requirement for > whatever replaces HTTP/1.1, since there is no better reason to replace > HTTP/1.1 (tokenizing or compression are hardly worth the bother given how > quickly mobile is catching up to PCs). I'd rather just replace TCP; > I expect that we'll need a protocol that can operate over multiple mux > and non-mux transports, because HTTP/1.1 works right now over many more > transports than just TCP and TLS. But mux over TCP is a reasonable start. > I'm sure you know this, but RFC2616 does not run over arbitrary transports. Different transports have different features, and that means HTTP maps onto them differently. TCP offers a single, bidirectional stream. SCTP offers multiple, unidirectional streams. In order to define how RFC2616 maps onto SCTP, a separate definition was needed: http://tools.ietf.org/html/draft-natarajan-http-over-sctp-01. It's not a complicated definition, but its not the only way to map HTTP onto SCTP. Mike > ....Roy > >
- Re: multiplexing -- don't do it Adrien W. de Croy
- multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Brian Pane
- Re: multiplexing -- don't do it J Ross Nicoll
- Re: multiplexing -- don't do it Mike Belshe
- RE: multiplexing -- don't do it Peter L
- RE: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Brian Pane
- Re: multiplexing -- don't do it Roberto Peon
- RE: multiplexing -- don't do it Peter L
- RE: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Alexey Melnikov
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Julian Reschke
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Poul-Henning Kamp
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Ian Fette (イアンフェッティ)
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Mark Nottingham
- Re: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Adam Barth
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Peter Lepeska
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: Re[2]: multiplexing -- don't do it Peter L
- Re[4]: multiplexing -- don't do it Adrien W. de Croy
- Re: Re[4]: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Amos Jeffries
- Re: Re[2]: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Amos Jeffries
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Poul-Henning Kamp
- Re: multiplexing -- don't do it Mark Nottingham
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Adrien W. de Croy
- breaking TLS (Was: Re: multiplexing -- don't do i… Stephen Farrell
- Re: multiplexing -- don't do it Roberto Peon
- Re: breaking TLS (Was: Re: multiplexing -- don't … Adrien W. de Croy
- Re: breaking TLS (Was: Re: multiplexing -- don't … Roberto Peon
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it Ray Polk
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it Mark Nottingham
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re: multiplexing -- don't do it J Ross Nicoll
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: breaking TLS (Was: Re: multiplexing -- don't … Adrien W. de Croy
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: breaking TLS (Was: Re: multiplexing -- don't … Mike Belshe
- Re: multiplexing -- don't do it Robert Collins
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: breaking TLS (Was: Re: multiplexing -- don't … William Chan (陈智昌)
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re[3]: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it patrick mcmanus
- Re: Re[3]: multiplexing -- don't do it Robert Collins
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re: multiplexing -- don't do it Amos Jeffries
- Re: multiplexing -- don't do it Stephen Farrell
- Re: multiplexing -- don't do it Amos Jeffries
- Re: breaking TLS (Was: Re: multiplexing -- don't … William Chan (陈智昌)
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it patrick mcmanus
- Re: breaking TLS (Was: Re: multiplexing -- don't … Amos Jeffries
- Re[2]: breaking TLS (Was: Re: multiplexing -- don… Adrien W. de Croy
- Re: breaking TLS (Was: Re: multiplexing -- don't … Martin Thomson
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Stephen Farrell
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: breaking TLS (Was: Re: multiplexing -- don't … Willy Tarreau
- Re: multiplexing -- don't do it Mike Belshe
- proxy config (was Re: multiplexing -- don't do it) Daniel Stenberg
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it J Ross Nicoll
- Re: multiplexing -- don't do it Stephen Farrell
- Re: breaking TLS (Was: Re: multiplexing -- don't … Henry Story
- Re: multiplexing -- don't do it Mike Belshe
- RE: proxy config (was Re: multiplexing -- don't d… Eric Lawrence
- Re: multiplexing -- don't do it Roy T. Fielding
- Re: multiplexing -- don't do it Poul-Henning Kamp
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Poul-Henning Kamp
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Patrick McManus
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it William Chan (陈智昌)
- options or protocols? Eliot Lear
- Re: options or protocols? Adrien W. de Croy
- Re: options or protocols? Willy Tarreau
- Re: options or protocols? Adrien W. de Croy
- Re: options or protocols? Willy Tarreau
- Re: options or protocols? Adrien de Croy
- Re: options or protocols? William Chan (陈智昌)
- Re: options or protocols? Willy Tarreau
- Re: multiplexing -- don't do it Patrick McManus
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Jon Leighton
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it Peter Lepeska
- Re: breaking TLS (Was: Re: multiplexing -- don't … Nicolas Mailhot
- HTTP -> Messages -> Transport factoring Mark Nottingham
- Re: HTTP -> Messages -> Transport factoring Mike Belshe
- Re: multiplexing -- don't do it Mike Belshe
- RE: HTTP -> Messages -> Transport factoring Henrik Frystyk Nielsen
- Re: HTTP -> Messages -> Transport factoring Mark Nottingham
- Re: multiplexing -- don't do it Jon Leighton
- Re: HTTP -> Messages -> Transport factoring Poul-Henning Kamp
- Re: HTTP -> Messages -> Transport factoring Willy Tarreau
- Re: HTTP -> Messages -> Transport factoring Willy Tarreau
- Re: HTTP -> Messages -> Transport factoring Carsten Bormann
- Re: HTTP -> Messages -> Transport factoring Poul-Henning Kamp
- Re: HTTP -> Messages -> Transport factoring Carsten Bormann
- Re: options or protocols? Adrien de Croy
- Re: HTTP -> Messages -> Transport factoring Mike Belshe
- Re: HTTP -> Messages -> Transport factoring David Morris
- Re: HTTP -> Messages -> Transport factoring Mike Belshe
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: breaking TLS (Was: Re: multiplexing -- don't … Nicolas Mailhot
- Re: breaking TLS (Was: Re: multiplexing -- don't … William Chan (陈智昌)
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: breaking TLS (Was: Re: multiplexing -- don't … Nicolas Mailhot
- Re: breaking TLS (Was: Re: multiplexing -- don't … Mike Belshe
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re: multiplexing -- don't do it Stephen Farrell
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Stephen Farrell
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Poul-Henning Kamp
- Re: multiplexing -- don't do it Roberto Peon
- RE: multiplexing -- don't do it Henrik Frystyk Nielsen
- Re: multiplexing -- don't do it Stephen Farrell
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: multiplexing -- don't do it Willy Tarreau
- Re: breaking TLS (Was: Re: multiplexing -- don't … Willy Tarreau
- Re: breaking TLS (Was: Re: multiplexing -- don't … Roberto Peon
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re: breaking TLS (Was: Re: multiplexing -- don't … Willy Tarreau
- Re: breaking TLS (Was: Re: multiplexing -- don't … Poul-Henning Kamp
- Re: breaking TLS (Was: Re: multiplexing -- don't … Willy Tarreau
- Re: breaking TLS (Was: Re: multiplexing -- don't … Daniel Stenberg
- Re: breaking TLS (Was: Re: multiplexing -- don't … Poul-Henning Kamp
- Re: breaking TLS (Was: Re: multiplexing -- don't … Roberto Peon
- Re: multiplexing -- don't do it tom
- Re: multiplexing -- don't do it tom
- Re: multiplexing -- don't do it patrick mcmanus
- Re: multiplexing -- don't do it tom
- Re: multiplexing -- don't do it Jamie Lokier
- Re: multiplexing -- don't do it Jamie Lokier
- Re: multiplexing -- don't do it David Morris
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Roberto Peon
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: Re[2]: multiplexing -- don't do it Poul-Henning Kamp
- Re[4]: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: multiplexing -- don't do it Jamie Lokier
- Portal authorization (was: Re: multiplexing -- do… Martin J. Dürst
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: Portal authorization (was: Re: multiplexing -… Nicolas Mailhot
- Re: Portal authorization (was: Re: multiplexing -… Nicolas Mailhot
- Re: Portal authorization Julian Reschke
- Re: Portal authorization Julian Reschke
- Re: Portal authorization Nicolas Mailhot
- Re: Portal authorization Julian Reschke
- Re: multiplexing -- don't do it Salvatore Loreto
- Re: multiplexing -- don't do it Amos Jeffries
- Re: Portal authorization Amos Jeffries