24

The backend server responds with a gzip file but without the Content-Encoding: gzip header. And I do not have control over the server so can't handle the issue server side.

What I need now is to decompress the gzipped file client side using javascript.

I have found this excellent library which can help me do this: http://nodeca.github.io/pako/

But I don't want to add additional library just to un-gzip a file. I feel that there should be a way to use the browser's native functionality to un-gzip. Am I correct? If I am wrong can someone explain why this browser functionality is not exposed as a javascript API? And is there a way to un-gzip a file in javascript without adding an additional library?

smnbbrv
  • 23,502
  • 9
  • 78
  • 109
Yash Agarwal
  • 955
  • 1
  • 13
  • 28
  • 2
    As far as I know you can't *force* a browser to un-gzip a page with javascript since you don't control how the browser renders the page. – Technoh Mar 23 '16 at 17:44
  • 1
    I make a get ajax request to fetch the file – Yash Agarwal Mar 23 '16 at 18:26
  • That's all good but if the server is not outputting the headers that match the content-encoding I believe you will have to manually un-gzip. – Technoh Mar 23 '16 at 18:27
  • 1
    I think the question is exactly about manually un-gzip, a resource fetched via ajax request not an entire page – Mohamed Ali Sep 07 '16 at 14:00

2 Answers2

13

The Compression Streams API is a new web standard and is currently available in Chromium, Firefox, Safari, and Deno.

Some example usage of the Compression Streams API:

async function decompressBlob(blob) {
  let ds = new DecompressionStream("gzip");
  let decompressedStream = blob.stream().pipeThrough(ds);
  return await new Response(decompressedStream).blob();
}

And for compression:

const compressedReadableStream = inputReadableStream.pipeThrough(new CompressionStream('gzip'));

You can also use a WASM implementation. Apparently WASM implementations can approach 90% of the performance of a native implementation (and ~20x the speed of a JS implementation).

See also:

joe
  • 3,752
  • 1
  • 32
  • 41
-2

The answer is wrong and should be deleted however can't be because of the platform restrictions. Ignore this in favor of another answer.

I feel that there should be a way to use the browser's native functionality to un-gzip. If I am wrong can someone explain why this browser functionality is not exposed as a javascript API?

No, there shouldn't be, unless it is in w3c standard and it is not. The only standard which says something about gzip compression is an HTTP standard.

I really believe it won't become standard because there are thousands of algorithms (for compression, encryption, etc.) which you may want to use and browsers cannot handle them all; it would also be unfair to create interfaces for one algorithm while not creating them for another.

HTTP protocol is a kind of exception. The compression here is done to make the life of millions of people easier. The HTTP is a bottle neck in web performance, so as long as the compression is available there I cannot imagine any case when you elsewhere need to use a compression in JavaScript. The only case I know is compressing items in a localStorage / indexedDB, but even there gzip won't work because it is not producing UTF-16 output.

That is why this is not in the standard and this is why it most likely won't appear there.

Your particular case is a server side implementation error. Using compressed output without a proper header really smells. Either don't use the compression or do it right.

And is there a way to un-gzip a file in javascript without adding an additional library?

Actually other than that there is a possible solution: create a browser extension which injects a proper header in a server response and you won't need a library but will need to distribute the extension to the users. Could be even worse, but still may work.

smnbbrv
  • 23,502
  • 9
  • 78
  • 109
  • 8
    One reason to offer application-available GZIP support would be for other protocols, like Web Sockets. – acjay Apr 03 '18 at 14:06
  • Definitely, this could be helpful. I am not against the idea of having the compression, but it is not there. However there is some sort of solution for web socket, https://stackoverflow.com/questions/11646680/could-websocket-support-gzip-compression – smnbbrv Apr 03 '18 at 14:26
  • 5
    `there shouldn't be, unless it is in w3c standard` - This is a misunderstanding of how the w3c started or continues to exist. Historically (and even quite recently) w3c does not **invent** standards for browsers to implement. Instead it usually adopts what browser makers can convince it to adopt as **standard** and hope others will stick to the new standard. So if Google Chrome and Firefox or Safari and Edge or Edge and Chrome etc. decide to make gzip API available to js it **WILL** soon be a w3c standard - not the other way around – slebetman Aug 18 '21 at 09:27
  • 3
    Heck, I should have scrolled down before leaving a comment. Joe's answer illustrates this standardization process nicely: Chrome implements a compression standard, a bunch of people start a working group, soon w3c will adopt it then 5 years from now it will be widely available. I know it's not fair because you can't know that joe will write the answer 5 years after you wrote your answer but even way back in 2016 this is how w3c standards work – slebetman Aug 18 '21 at 09:31
  • This answer didn't age well at all. At this point it is pretty much a wrong answer, and should not be marked as the accepted answer. – Jorge Galvão Aug 07 '23 at 08:11
  • @JorgeGalvão you are totally right. However I cannot remove it since it is accepted, and cannot remove the acceptance. – smnbbrv Aug 08 '23 at 09:42