- From: Patrick McManus <mcmanus@ducksong.com>
- Date: Mon, 16 Jul 2012 09:25:51 -0400
- To: Yoav Nir <ynir@checkpoint.com>
- Cc: Mark Nottingham <mnot@mnot.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, 2012-07-16 at 11:51 +0300, Yoav Nir wrote:
> While Chrome and Firefox update often, many servers hardly ever get
> updated. We'd need a very good reason for any departure from what
> SPDY/3 currently is, especially for any change that is not backwards
> compatible with the current SPDY.
>
This is an important topic, and I think you have it (understandably)
wrong. Go ahead and break spdy/3 radically if that is right thing to
technically do!
SPDY is an experiment undergoing rapid change and standardization is
definitely part of that transition. If you cannot keep up with that
change you shouldn't be deploying it at this early stage of development.
I have spent a lot of time talking with many of the server side
implementations of spdy explaining that spdy/2 will be pushed off the
network from firefox probably at the time of deploying spdy/4...
followed by spdy/3 being pushed out by spdy/5, etc.. Nobody believes
that spdy is mature enough that we want it to be a defacto standard
forever.
At IETF-paris the chrome team and I had this discussion as well - I
can't speak for them or their algorithm but I can say in our discussion
they were even more adamant this general point than I am here. This
thing is totally breakable without leaving a trail of N versions to
support in its wake. That would be a disaster.
The realities of NPN deployment of SPDY make this easy during
standardization. Right now everyone running SPDY is running both HTTP/1
and some set of {spdy/2, spdy/3}.. If you had a (http/1 and spdy/2)
server that did not get any spdy updates by the time firefox dropped
spdy/2 support http/1 would silently be negotiated in its place. So
interop at least would continue.
-Patrick
Received on Monday, 16 July 2012 13:26:26 UTC