Implementation Notes on Server Push

I'm wrapping up a Firefox implementation of spdy/3 server push and wanted
to provide some ietf level feedback because that mechanism is largely
intact in the current http2 work in progress draft.


   - 304's seem to be a common cause of wasted pushed streams. I would see
   servers respond with a 304 for index.html and still push 200 responses for
   a.css and b.js when in a non-push world that would have been either 1 or 3
   304's. Maybe we should have a rule that you can only push to an
   assoc-stream of 2xx ?
   - There is language in the spec that if the client resets a stream that
   it implicitly resets any associated streams too. That was complicated to
   implement and pretty much broke my stream state model internally - while
   researching it it appears that mod_spdy and chrome don't implement it at
   all. The spec has an editorial note about removing that feature and I favor
   that removal.
   - I found flow control for pushed streams immensely helpful. It lets the
   client bound how much data can be pushed before there is a local GET
   matched up with that. Relatedly, I changed my default SETTINGS window size
   from a ~infinite value to be a smaller push-apropos value and then
   pipelined a window update with each odd SYN_STREAM to make pulled streams
   ~infinite again while preserving the smaller limit for push and this worked
   fine with all existing servers to my pleasant surprise. That seems to mean
   at least the spdy/3 windowing mechanism is simple enough for people to get
   right.
   - As with other parts of the spec, I was faced in some implementations
   with some very large data frames (90+KB) from servers when testing. Such
   frames are impervious to CANCEL or any mechanism we might use to change
   priorities driven by the client :(..  HTTP2 is doing the right thing by
   creating a smallish max frame size.


Obviously this is implementation experience with testing and isn't real
operational experience yet.. that will come.

-P