- From: Adam Barth <w3c@adambarth.com>
- Date: Sat, 31 Mar 2012 10:17:38 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Mike Belshe <mike@belshe.com>, Julian Reschke <julian.reschke@gmx.de>, "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>
On Sat, Mar 31, 2012 at 4:54 AM, Mark Nottingham <mnot@mnot.net> wrote: > > On 31/03/2012, at 1:11 PM, Mike Belshe wrote: > >> 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… > > Mike - > > I don't disagree on any specific point (as I think you know), but I would observe that the errors you're talking about can themselves be viewed as transient. I.e., just because they occur in experiments now, doesn't necessarily mean that they won't be fixed in the infrastructure in the future -- especially if they generate a lot of support calls, because they break a lot MORE things than they do now. > > Yes, there will be a period of pain, but I just wanted to highlight one of the potential differences between deploying a standard and a single-vendor effort. It's true that we can't go too far here; if we specify a protocol that breaks horribly 50% of the time, it won't get traction. However, if we have a good base population and perhaps a good fallback story, we *can* change things. That's not our experience as browser vendors. If browsers offer an HTTP/2.0 that has a bad user experience for 10% of users, then major sites (e.g., Twitter) won't adopt it. They don't want to punish their users any more than we do. Worse, if they do adopt the new protocol, users who have trouble will try another browser (e.g., one that doesn't support HTTP/2.0 such as IE 9), observe that it works, and blame the first browser for being buggy. The net result is that we lose a user and no pressure is exerted on the intermediaries who are causing the problem in the first place. These are powerful market force that can't really be ignored. Adam > Just my .02. > >> 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 tend to agree with the point you made in the meeting -- this probably falls into the noise of other errors / discomforts in the mobile world. Mobile users have low expectations. > > Cheers, > > > -- > Mark Nottingham > http://www.mnot.net/ > > > > >
Received on Saturday, 31 March 2012 17:18:41 UTC