Open rmarx opened 4 years ago
treat .qlog.zip, .qlog.gz and .qlog.br as normal .qlog in both qvis and qvis-server
Don’t you have to gunzip it first?
I'm hoping that I can download them at the server and then just set the correct content_encoding when sending it back to the frontend, allowing the browser to do the decompression... hoping being the keyword there ;)
Update: 1: This cannot be done directly in the browser. So now we just look for an error. If we get that, we try again via the server (if it was a genuine 4xx the first time we wasted another request, but too bad)
2 - 4: https://github.com/quiclog/qvis/commit/29d3aaa3a858d64aa70518d113ff8bf42d33fbee, https://github.com/quiclog/qvis/commit/bab59db7c6d0263228ced809e146ee7dc10e1fae and https://github.com/quiclog/qvis-server/commit/3759662f822557bcf478c1049c42a2a844a9a85f. Our hope was valid: qvis-server can just proxy the files and set the correct Content-Encoding and it works (or at least it seems to ;))
As a side-effect, we now also try to fetch files inside the browser first. If CORS is setup properly, no more backend interaction is necessary!
5: TODO
Some testfiles one can use:
This is something the browser can do without issue. However, when downloading qlog from an external endpoint, we currently go through qvis-server to prevent CORS issues... and the qvis-server introspects the qlog etc. and not sure how the nodejs request library handles gzip/brotli.
Plan: