2 ms·
> but no browser actually does this today, and the first part of the file gets sent down regardless. Are browsers really not doing this? My understanding was t
by forgotpwtomain 10y ago
> but no browser actually does this today, and the first part of the file gets sent down regardless.
Are browsers really not doing this? My understanding was that just one round-trip was wasted for the client to send an RST_STREAM frame, or does it really re-download the entire pushed file where normally it would be a 304 on request?
- dfabulich 10y agoThe RST_STREAM frame is, indeed, how the browser was supposed to abort the download, per the spec. But it's a SHOULD, not a MUST. In fact, browsers just don't do it. So why not? Priorities. Not very many sites are using push, and this is partly due to a chicken-and-egg problem; push isn't that good, so nobody's uses it, so there's not much incentive to make push better. But even if new browsers started correctly aborting pre-cached pushes today, that still wouldn't be as awesome as Cache Digests, which could avoid re-pushing cached content without wasting any bytes. So, if you're going to spend a few minutes working on H2 Push, you should probably spend it working on Cache Digests, rather than working on aborting pushes. And Cache Digests can even be polyfilled by Service Workers, which are incredibly powerful in their own right. So if you're not Chrome or Firefox, rather than even spending time on Cache Digests, you should probably focus on implementing Service Workers first, so the users can at least polyfill their way out of the problem. So the order should be: Service Workers first, then Cache Digests, then push-aborts. So, uh, don't expect to see any push aborts from the major browsers any time this year, IMO.