Cache-control integration ?

[healiha]

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 and Content-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 and Content-Length.

It would be necessary to check for some change from the request header, to verify if file must be resend.

[riaan53]

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

[healiha]

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.

[puzrin]

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.