You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I gunzip it once as a binary array of bytes, and then gunzip that result a second time and specifically force it to decode that as a string, I can recover the contents.
constgzdata: any=awaitBlobUtil.blobToArrayBuffer(blob)constgunzip1=pako.inflate(gzdata)constgunzip2=pako.inflate(gunzip1,{to: 'string'})console.log(gunzip2)// <?xml version 1... etc>
Chrome and Firefox are handling this differently: firefox returns a "double-gzipped" blob whereas Chrome is providing a singly-gzipped blob.
By turning off gzip in Dropwizard, the two browsers both end up with a once-gzipped file.
@Janekdererste is going to explore more fine-grained settings for Dropwizard so that both browsers behave properly, and we don't have to double-unzip everything, and text files still get gzipped for efficiency.
In the UI code, FileAPI.downloadFile() returns the correct blobs for any file OTHER THAN a gzipped file.
Gzipped files are returned with extra bytes somehow; they are corrupted and un-gunzippable.
This could likely be some sort of NGINX interaction problem.
The text was updated successfully, but these errors were encountered: