{"items": [{"author": "Jeff Kaufman", "source_link": "https://plus.google.com/103013777355236494008", "anchor": "gp-1432065473790", "service": "gp", "text": "@Ilya\n\u00a0\n@Josh\n\u00a0", "timestamp": 1432065473}, {"author": "Jan-Willem", "source_link": "https://plus.google.com/100580955183019057735", "anchor": "gp-1432073103005", "service": "gp", "text": "So the browser is taking the pushed 304 as an empty pushed resource? \u00a0That'll be annoying to fix, I bet.", "timestamp": 1432073103}, {"author": "Ilya", "source_link": "https://plus.google.com/114552443805676710515", "anchor": "gp-1432076358974", "service": "gp", "text": "@Jeff Kaufman\n\u00a0node-http2 should work, I was playing with it earlier today. Guessing, it's bailing due to some TLS misconfiguration -- HTTP/2 is much stricter about valid certs and all that stuff.\u00a0\n
\n
\nMore importantly though.. The 304 + Server Push does (almost) work:\u00a0\nhttps://gist.github.com/igrigorik/84e79bfb97ebc90ca553\n -- see the netlog trace. On first request (\"/\") the client requests script.js file by itself and gets a Last-Modified timestamp. Then, when the client hits \"/?next\" we push a 304 against script.js and the push stream is \"adopted\".\n
\n
\nThat said, see the gotcha note in the server.rb file: pushing a 304 against a non-existent record creates it in the Chrome cache.. with an empty body. FWIW, this doesn't seem right, it seems like Chrome should discard such entries -- if that's doable, then I think this technique would actually work quiet well.\n
\n
\n/cc \n@Chris\n\u00a0\n@Patrick", "timestamp": 1432076358}, {"author": "Mark", "source_link": "https://plus.google.com/117348597427239540873", "anchor": "gp-1433914677273", "service": "gp", "text": "The other way to go about it is to push the 200, but for 1RT after the response headers have gone out, give the stream a lower weight. That covers this case as well when the cache is empty.", "timestamp": 1433914677}, {"author": "Ilya", "source_link": "https://plus.google.com/114552443805676710515", "anchor": "gp-1433916753406", "service": "gp", "text": "@Mark\n\u00a0as in, 200 marks the previous response body as \"valid\" which allows the UA to read it from cache (hence the 1RT delay)? Because if so, then that seems kinda risky.. the 200 could be for an alternative response, it seems UA should block and wait.\u00a0", "timestamp": 1433916753}, {"author": "Mark", "source_link": "https://plus.google.com/117348597427239540873", "anchor": "gp-1433916808899", "service": "gp", "text": "@Ilya\n\u00a0200 + response headers (which includes the etag)", "timestamp": 1433916808}, {"author": "Ilya", "source_link": "https://plus.google.com/114552443805676710515", "anchor": "gp-1433916976466", "service": "gp", "text": "@Mark\n\u00a0ah, interesting. Hmm, how is that better than browser processing the pushed 304? The empty cache scenario there is: push 304, client drops it because there is no such cache entry and requests resource as usual.", "timestamp": 1433916976}, {"author": "Mark", "source_link": "https://plus.google.com/117348597427239540873", "anchor": "gp-1433917121763", "service": "gp", "text": "@Ilya\n\u00a0having an extra RT's worth of response body (admittedly at diminished rate), having response headers immediately.", "timestamp": 1433917121}, {"author": "Ilya", "source_link": "https://plus.google.com/114552443805676710515", "anchor": "gp-1433918382880", "service": "gp", "text": "@Mark\n\u00a0I see, but it also has the downside of incurring that RT's worth of response on revalidation's..", "timestamp": 1433918382}, {"author": "Mark", "source_link": "https://plus.google.com/117348597427239540873", "anchor": "gp-1433918579963", "service": "gp", "text": "@Ilya\n\u00a0Yeah; it's a balance / judgement call. If we're talking about \nreally\n short freshness lifetimes, you're betting for/against the cache eviction algorithm + cache size / activity.", "timestamp": 1433918579}]}