W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Implementation Notes on Server Push

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Tue, 14 May 2013 15:14:59 -0400
Message-ID: <CAOdDvNqXhG7+xbvBwctQCR4tZePKByw75SR5oBamXTymZa7myA@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
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
   - 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.

Received on Tuesday, 14 May 2013 19:15:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:11 UTC