Electron block blob uploads resuld in DisableResponseDecompressionPolicy not available in browser Error

[MGibson1]

• Package Name: @azure/storage-blob
• Package Version: 12.4.1
• Operating system: Mac
• nodejs
  • version:
• browser
  • name/version: electron/11.1.1
• typescript
  • version: 3.8.3
• Is the bug related to documentation in
  • README.md
  • source code documentation
  • SDK API docs on https://docs.microsoft.com

Describe the bug
I have code shared throughout multiple typescript repositories which references storage-blob to upload files to a block blob using a URI received from a Server which generates a limited-life blob create URI. In Node and browser environments this code works correctly, but my Electron environment complains that: Error: DisableResponseDecompressionPolicy is not supported in browser environment

To Reproduce
Steps to reproduce the behavior:

1. Implement block blob storage in an electron environment.
2. Attempt upload using blob URI + SAS
3. Observer failure

Expected behavior
Library should correctly upload a file when in electron.

Additional context
The library code I'm using can be found here: https://github.com/bitwarden/jslib/blob/direct-upload-and-download-of-send-files/src/services/send.service.ts#L276-L278. This repository is referenced in multiple clients with the expectation that in each an ArrayBuffer is just uploaded to the given blob URI.

The fact that my code works in both Node and browser-based clients leads me to believe that however storage-blob is detecting if it's in a Node environment is being tricked by Electron to the wrong answer.

Any help or a method to just directly send a PUT request to my blob URL would be fantastic.

[ramya-rao-a]

Thanks for reporting @MGibson1
@maorleger Did you see something similar when you were trying out the Storage SDKs in electron apps?

[maorleger]

@ramya-rao-a I don't recall this error and I used that API, but I did have nodeIntegration: true in my sample so Node APIs were available in the renderer/browser process.

When I did run into a different issue in Electron @JasonYeMSFT was a good resource and might be able to know what could be happening.

[ljian3377]

@MGibson1
Have you set nodeIntegration: true? Could you share more about your code structure?

disableResponseDecompressionPolicy is only available in Node.js.

export const isNode =
  typeof process !== "undefined" &&
  !!process.version &&
  !!process.versions &&
  !!process.versions.node;

  if (isNode) {
    // policies only available in Node.js runtime, not in browsers
    factories.push(proxyPolicy(pipelineOptions.proxyOptions));
    factories.push(disableResponseDecompressionPolicy());
  }

" In Node and browser environments this code works correctly,"

Did we miss anything? Adding @jeremymeng for visibility.

[MGibson1]

Hi @ljian3377, Thanks for your reply.

We do have nodeIntegration: true set on the window doing the work.
https://github.com/bitwarden/jslib/blob/df59f99ec649c1f4a75456e1e5a3c0f98de0e9c1/src/electron/window.main.ts#L120

I'm sorry I'm not sure what would be relevant about the code structure. Could you be a little more specific? In general the intention is to request a SAS-authorized url to a specific blob and upload a file to that blob. This occurs in a BrowserWindow with nodeIntegrations: true.

One of my coworkers, @Hinton, noticed that in serviceClient there appears to be an option to turn response decompression off. Is that a viable option to fix?

azure-sdk-for-js/sdk/core/core-http/src/serviceClient.ts

Line 827 in f68f3fe

requestPolicyFactories.push(disableResponseDecompressionPolicy());

I don't think you missed anything in the node detection, and it does return true in my BrowserWindow. The disableResponseDecompressionPolicy is definitly being applied to the request, the issue might be why isn't it working? Is there another location that tests if the policy is valid and may have a different definition of Node being present?

[jeremymeng]

The replacement for browser is specified in core-http package.json "browser" field:

azure-sdk-for-js/sdk/core/core-http/package.json

Line 53 in 8e14c7a

"./es/src/policies/disableResponseDecompressionPolicy.js": "./es/src/policies/disableResponseDecompressionPolicy.browser.js",

.

It seems that somehow Electron picked the browser replacement? Though what I read about was that Electron doesn't follow the browser field.

We could probably change the browser version of disableResponseDecompressionPolicy to log warnings instead of throwing. @bterlson @xirzec @chradek thoughts?

[ljian3377]

@MGibson1
Could you help verify if the browser version file of disableResponseDecompressionPolicy is being used?
https://github.com/Azure/azure-sdk-for-js/blob/78db83fe148b8dad1fe8db4112cf92b45ffb13d3/sdk/core/core-http/src/policies/disableResponseDecompressionPolicy.ts
https://github.com/Azure/azure-sdk-for-js/blob/ab612a816be2b71e8c33280a298b1cd6b475aa10/sdk/core/core-http/src/policies/disableResponseDecompressionPolicy.browser.ts

Or you can share how to recreate the issue with your repo so @EmmaZhu can recreate it.

And this code is in a quite common code path. It should be already hit if there is such an issue.
Adding our Electron expert @JasonYeMSFT to share some insight on the usage.
https://github.com/bitwarden/jslib/blob/df59f99ec649c1f4a75456e1e5a3c0f98de0e9c1/src/electron/window.main.ts#L120

[ghost]

Hi, we're sending this friendly reminder because we haven't heard back from you in a while. We need more information about this issue to help address it. Please be sure to give us your input within the next 7 days. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!

[JasonYeMSFT]

I don't have much knowledge to share here since we don't use the SDK in a browser process and we don't use that flag "DisableResponseDecompressionPolicy" neither.

[ghost]

Hi, we're sending this friendly reminder because we haven't heard back from you in a while. We need more information about this issue to help address it. Please be sure to give us your input within the next 7 days. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!