Online serves lots of JS, SVG etc. via HTTP[S]. If the client flags that they support gzip in their request header; ie. the request has a header containing 'gzip' eg. Accept-Encoding:gzip, deflate, sdch, br Then we should send a response with this header: Content-Encoding:gzip And serve up an internally cached copy of the file which is gzipped; checkout: net/Socket.cpp: namespace HttpHelper { inline void sendFile(const std::shared_ptr<StreamSocket>& socket, const std::string& path, Poco::Net::HTTPResponse& response) Ideally we should build and pre-populate a set of all files and their gzipped' versions in memory on startup - and only serve these (which would also be useful for security and avoids the need to do careful path resolution in wsd/FileServer.cpp). We can use: Poco's DeflatingOutputStream to read and deflate those (I hope) - but lets only support 'gzip' encoding. Thanks !
Hi, I would like to work on this issue.
Hi, So, i have been working on this issue and trying to solve it. As of now i am able to send gzipped version of requested files with appropriate headers, but there is a small issue that i am facing. The uncompressed version of the files as shown in the browser, do not exactly match the original file i.e. they contain some stray characters. I have attached a screenshot of such file. As per my understanding, this issue might be because of the size of blocks being sent for compression, but i haven't been able to resolve this. I would be very thankful for any help. : )
Created attachment 132014 [details] Strange characters in js file
Assigning per comment 1. Please reset assignee if you decide to stop working on this. Solution proposal is on: https://gerrit.libreoffice.org/35429
dewana-dewan committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/online/commit/?id=432204566764e88266370738686ed6a8d1dd31c4 tdf#106579 - serving gzipped file content
Thanks for the fix; closing the issue. Another thing to do here is to pre-load all of these files into memory at startup, to pre-compress them (omitting eg. PNGs which are already deflated) - and to serve the files from an internal hash. Is that something you could work on and/or include in your GSOC proposal (sorry to steal that from you Noel). If we pre-compress, then getting content-length right should be easy too. Thanks !
Thanks for the suggestion sir, I would definitely love to work on this and include this in my gsoc proposal.
Submitted a new patch for doing gzip compression instead of deflate, as was initially planned. https://gerrit.libreoffice.org/#/c/36448/