I support this general approach while we work on standardization. No
flag days, but rather finite (and flexible) transition periods.
Once we reach a (hopefully) ietf proposed standard RFC level, then it is
suitable to talk about long term backwards compatibility. But until
then, let's iterate as quickly as we need to[*] and make sure deprecated
versions get the heck off the Internet. It certainly helps that HTTP/1
is pragmatically a fallback for implementations that fall way behind.
-Patrick
[*] a plea for discipline while we iterate: don't make official releases
of interim draft edits.. we should all have a single fixed value of what
v3 is and that should be unambiguous and once we have that discussion
should be focused around evolving v4.
The main use of per-stream flow control is to protect proxies from
having to infinitely buffer POST data if data on the stream is coming
at a rate that is higher than what it can process while still
preventing head of line blocking from happening on the reader side
SPDY connections.
Flow control should have no effect on small requests and responses,
but could severely limit throughput on high bandwidth delay product
links. We will likely include recommendations once we have more data
from our experiments.
That's a good use case, but browser's consuming responses care too.
Especially when coordinating things like active tabs vs stalled/jerky
plugins that might be flowing over the same spdy session. The same
buffering conundrum exists that you describe with the proxy and the
right thing to do is to let the content source feel the back pressure
without screwing up the other streams.
so +1 flow control :)
Sorry my bad questions.What I want to know is why the definition of the length of Data Frame and the Length of Control frame is different.