Closed kjetilho closed 3 years ago
This is probably out of scope for this add-on. It's the responsibility of the server to set the correct response header that allows the browser to recognize the compression and then decompress it.
Do you have any examples where this functionality would be needed / desired?
It does set a gzip mime type. You think I should make a wrapper script and foist it over to it instead? That would work, of course.
Example: https://copr-be.cloud.fedoraproject.org/results/jdoss/wireguard/epel-8-x86_64/repodata/
(I do not expect sqlite support ;)
I was originally thinking of forcidbly changing the response headers, to Content-Encoding: gzip
to get the browser to automatically uncompress .gz
files, plus forcing the Content-Type
to application/xml
. This did not work for your given test case because there is a byte order mark (BOM) at the start of the uncompressed XML file.
bz2
encoding is not natively supported by the browser. An extension could try to decompress it (by modifying the response body via the filterResponseData
API).
sqlite support etc. is obviously not feasible.
What you're asking for requires active modification of response bodies, which is outside the scope of this project. If you are interested in building something relevant yourself, see:
It would be super useful if Open-in-browser could uncompress files before presenting them to the browser. Just handling them as TXT would be a good start.