On Tue, Aug 21, 2012 at 3:00 PM, Roberto Peon <grmocg@gmail.com> wrote: > > > On Tue, Aug 21, 2012 at 1:47 PM, Yoav Nir <ynir@checkpoint.com> wrote: > >> >> On Aug 21, 2012, at 10:14 PM, Poul-Henning Kamp wrote: >> >> We should if it's possible. Suppose HTTP/2.0 looks much like the SPDY >> draft. >> >> How can you ever get a current HTTP/1 server to reply to this? >> > >> > That's why I've been saying from the start that SPDY was an interesting >> > prototype, and now we should throw it away, and start from scratch, >> being >> > better informed by what SPDY taught us. >> >> A requirement for downgrade creates too many restrictions, even if we >> throw SPDY away. The beginning of a 2.0 connection would have to look >> enough like 1.x so as to fool existing servers. >> >> > Note that we'll always have to do downgrade-- perhaps someone deploys a > proxy which doesn't speak HTTP/2, or perhaps the site administrator deploys > a different server or load balancer that only speaks HTTP/1.1 when it used > to do HTTP/2. > These will happen and must be addressed. > > >> I think we should live with upgrade only, as long as clients can cache >> the knowledge that a certain server supports 2.0, so that they can skip the >> upgrade the next time. The extra roundtrip on a first encounter is not that >> bad. >> > > I disagree-- I want the user to experience the lowest latency possible for > all sites possible whenever possible! :) > > The more I read through this conversation, the more I worry that all this talk about zero-latency upgrade negotiation through multiple hops of arbitrary 1.1 or 2.0 servers is going to lead to significantly more complexity than originally hoped -- and not the acceptable good kind of complexity that delivers real benefits in the end. - James > -=R >
Received on Wednesday, 22 August 2012 00:53:34 UTC