Re: multiplexing -- don't do it

On Sat, Mar 31, 2012 at 01:11:53PM +0200, Mike Belshe wrote:
> 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.

I think that instead, many mobile vendors deploy transparent proxies to
speed up browsing, and since these are recent products, they support
pipelining pretty well. But if the mobile browsers were to connect to
the net directly and try pipelining, there would still be a number of
surprizes. That said, opera ships with pipelining turned on by default
and does pretty well, as I don't remember having observed a single
hang (I don't know how many tricks they involved for this).

> 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.

It would be nice to have the same data with a fallback mechanism, because
I suspect it's much more reliable than what has been measured for a use with
WS, which requires a mandatorily non-compatible upgrade.

None of my corporate customers currently let unknown ports pass through their
proxies, and none of them will be willing to blindly open that without the
ability to inspect requests flowing there. The advantage of port 80+Upgrade
is that current filtering policy still works, and if the product is not 2.0
compatible, 1.1 is kept for all the session, which I expect to result in a
much better overall success than a commonly closed port.

Regards,
Willy

Received on Saturday, 31 March 2012 11:30:56 UTC