W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: multiplexing -- don't do it

From: Adrien W. de Croy <adrien@qbik.com>
Date: Sat, 31 Mar 2012 10:25:30 +0000
To: "Julian Reschke" <julian.reschke@gmx.de>, "Mike Belshe" <mike@belshe.com>
Cc: "Alexey Melnikov" <alexey.melnikov@isode.com>, "Roberto Peon" <grmocg@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <emdb617f7a-4498-4441-8788-8ca91aa1d116@boist>

------ Original Message ------
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Mike Belshe" <mike@belshe.com>
Cc: "Adrien W. de Croy" <adrien@qbik.com>;"Alexey Melnikov" 
<alexey.melnikov@isode.com>;"Roberto Peon" 
<grmocg@gmail.com>;"ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 31/03/2012 7:57:03 p.m.
Subject: Re: multiplexing -- don't do it
>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. 
>
>>... 
>>Options simply don't work - we need to make this stuff mandatory from 
>>the get-go or it is very likely to have the same result that we've 
>>seen 
>>in the past. 
>>... 
>
>I don't think that's correct. 
>
>Options do not work if and only if they are usually not switched on. 
>
>For instance, if header compression is optional, but common UAs will 
>use it by default, it *will* be implemented. 
>
>Also, this is a feature that can trivially tested in a test suite. 
  
and trivially implemented.
  
Pipelining wasn't supported in WinGate because basically it's onerous.  
It's hard enough for a proxy taking on the responsibility to deal with 
the problem cases relating to pipelining (which may not be able to be 
simply reflected back through to the client).  But every filter in the 
filter chain also therefore needs to be able to cope with retries etc.
  
In a proxy there can be side-effects in the proxy to every request 
regardless of whether it's safe/idempotent for the server.  Some 
side-effects are user configurable, and may affect subsequent 
processing of requests. Retries even if safe for the web application, 
can cause problems for the proxy.  So, we stop reading off the buffer 
when we've received a whole request, which serializes the whole thing.  
  
Deterministic multiplexing OTOH would be a lot simpler, even if 
upstream is 1.1
  
Adrien
  
  
>
>
>Best regards, Julian 
Received on Saturday, 31 March 2012 10:25:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:57 GMT