Closed healiha closed 2 years ago
Hi @healiha ,
Wont the client just request the file based on the cache settings sent by the http server? So gridfs-stream does not know anything about the cache - it just stream data if requested.
I have done a simple cache implementation in meteor-file-collection (just x amount of time if specified in url) here https://github.com/riaan53/meteor-file-collection/blob/master/http_access_server.coffee#L148 . So the client wont request an image or video again if it was cached.
Is this want you mean?
Regards, Riaan
Hi @riaan53 ,
That it. I already started an implementation here https://github.com/healiha/gridfs-stream/blob/master/lib/index.js#L163-L204 .
The only differences are that I use the ETag
header instead of Content-MD5
and Cache-Control
set to public, max-age=0
.
It's still incomplete though. Would be easier to use if exported to a new dependencie with pipe supports.
Regards, Lilian.
I see no profit of adding headers manipulation into gfs stream, because that's already covered in fresh and other packages.
See example: https://github.com/nodeca/nodeca.core/blob/master/lib/autoload/hooks/server_bin/gridfs.js
Also, i'd recommend to look into send src to learn how to work with headers properly.
I was wondering if it would be wise to add Cache-control(client-side) to gridfs-stream ?
What we basically need to do is add
Pragma
,Accept-Ranges
,Cache-Control
,ETag
,Last-Modified
,Content-Type
andContent-Length
headers, and set the statusCode to 304 before sending the file to client.Then for each ulterior call to this file by a client we do the same thing again but this time without sending
Content-Type
andContent-Length
.It would be necessary to check for some change from the request header, to verify if file must be resend.