Hardening: Compression
mitsuhiko opened this issue · comments
Today the spec says this:
The file is allowed to be GZIP compressed. It is not expected that in-browser consumers of the the source map will support GZIP compression directly but that they will consume an uncompressed map that may be GZIP'd for transport.
I think the way compression is handled is all over the place from not handled, expected to be decompressed via browser etc. Some tools also support brotli.
Could using the standard Accept-Encoding/Content-Encoding headers when returning the sourcemap (or sourcemap-containing script) be sufficient to avoid re-specifying how compression for sourcemaps works?
I think the spec wording is just confusing. To me it sounds like it is talking about compression (overly specific as a sign of its time) and about encoding:
It is not expected that in-browser consumers of the the source map will support GZIP compression directly but that they will consume an uncompressed map that may be GZIP'd for transport.
My reading: "It is not expected that DevTools will just blindly decompress a compressed source map response itself but that they will consume an uncompressed map that may have been compressed for transport via Accept-Encoding etc. and was decompressed by the general browser resource loading machinery."
We discussed that we will remove this from the spec and then figure out an improved wording about how source maps should be fetched in terms of the fetch API.