How to handle dynamic compression in embeded resources?
aloksharma1 opened this issue · 8 comments
Hello,
now that i have replaced static file middleware with yours and removed responsecompression middleware, how do you suggest we do compression on fly for dynamic resources embeded in dll files (e.g. RCL in my case).
thanks
This library only works with file located directly on disk, but one idea would be to have a post build step that extracts the files to disk? This way it should magically work.
What is RCL? And how are those files served without this library?
RCL is reusable razor class library check here, i am serving those files using ManifestEmbeddedFileProvider , extracting and putting these files in new places doesnt make sense in this case; they are mostly for backend.
If they are mostly for backend what is the point of being able to serve them compressed?
But any way this library doesn't support embedded files natively but you could try to add a custom IAlternativeFileProvider but I'm not 100% that it will work, and if you do i have no idea where to store the compressed versions of the files.
On second thought it might work right out of the box if you embed the compressed files in the same place as the uncompressed files, the middleware should use the ManifestEmbeddedFileProvider and discover both versions.
But i have no idea how to add the compressed versions to the same assembly.
the second option is good, but i have way too many files to consider. what if i change the priority of your middleware with response compression middleware ? will both work in that case?
ok i did some tinkering, here is my solutions if anyone needs it in future:
- filewatchers are not helpful as its embedded resources, the only good way is using second option suggested by peter.
- now dynamic iis compression also does the job, but this kills the purpose of saving resources in first place
- so we have to add a small middleware listen for stream and and queue for the embedded file for compression and store it on disk (this is still the best solution as compression will only happen once & in my case i have 1000s of such files so i cant increase dll size any further).
If you would move the extract and compression to build time instead of runtime then you could use zopfli giving you smaller gzip files. (Might increase build time a lot so only do this when building a release version)
Added benefit is that you don't risk any old files being used instead of the new ones.. (Don't know how you deploy but if its a simple copy and paste and you don't delete your compressed files, then you might serve a compressed file with old content)
as i said, only problem is very huge directory & unknown number of files.. .also i am using broltisharp & zopfli with on fly middleware giving same amount of compression.
thanks for the input though.