Closed ronkorving closed 8 years ago
Hm... I think it should be correct to just send a push promise, and defer sending data until then? You will need to include some headers with it, though.
Whatever I do, the stream wants an end() and it sends that as content.
@ronkorving aaah, so you want to just let know the client that the cached resource is valid?
It doesn't look that such case is explicitly specified by spec. Perhaps @igrigorik may help us a bit?
I think you're looking for rel=preload. Chrome implementation is underway.
@igrigorik thanks for that, that's very interesting @indutny well, what's the point of push promises, if it completely ignores all the browser's caching logic? why push files that it may already have?
@ronkorving the idea is that browser will cancel the promises if it has the data for them.
Oh, I had no idea. It cancels the stream? (got a source for that? do browsers actually do this in practice?) For that it would at least need all the right headers (ETag, last-modified, etc) I guess, but that's inevitable anyway.
Yep! You got it
Now the big question is how to make this play nice with Express :) Wish I could re-use the logic of res.sendFile (etc) on the push stream.
This is not really an issue, and more like a question, so I'm going to close it. Feel free to reopen if you consider it to be an issue!
When my client already has certain files cached, it seems like an error to send back a bunch of files blindly in a
push()
call. Can anyone share any advice on how (if at all possible) to tell the client it will need to download more, but not yet give it the data (or even the typical HEAD response with ETag etc as I may not have one ready yet). Really all I have at the moment are just URLs I could send to the client. Thanks.