Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Copy URL command unexpectedly encodes "/" as "%2F" #2939

Closed
craxal opened this issue May 6, 2020 · 12 comments
Closed

Copy URL command unexpectedly encodes "/" as "%2F" #2939

craxal opened this issue May 6, 2020 · 12 comments
Assignees
Labels
🪲 regression Issue was working in a previous version ✅ merged A fix for this issue has been merged
Milestone

Comments

@craxal
Copy link
Contributor

craxal commented May 6, 2020

Storage Explorer Version: 1.13.0
Build Number: 20200430.5
Platform/OS: All
Architecture: All
Regression From: 1.12.0

Bug Description

In previous versions of Storage Explorer, Copy URL returned a URL like this:
https://myaccount.blob.core.windows.net/mycontainer/folder/file.html

However, in 1.13.0, COPY URL returns a URL with encoded slashes like this:
https://myaccount.blob.core.window.net/mycontainer/folder%2Ffile.html

For many file types, this isn't an issue. But if I paste the encoded URL into a browser window, some files don't open properly, such as HTML files generated by Adobe Animate CC.

Steps to Reproduce

  1. Launch Storage Explorer and open a blob container.
  2. Set the container's Public Read Access to "blob".
  3. Create a virtual folder in the blob container.
  4. Upload an HTML file generated by Adobe Animate CC to the virtual folder.
  5. Right-click the uploaded blob and select Copy URL.
  6. Paste the copied URL into a browser window.

Expected Experience

The file opens and performs as expected.

Actual Experience

The file opens with errors or missing components.

Additional Context

This bug was originally reported by @egdedudette.

@cicorias
Copy link
Member

cicorias commented May 6, 2020

I just saw this today after updating Storage Explorer.

I can confirm that if I navigate via the Azure Portal (portal.azure.com) to the same container/file and use the "Copy" to clipboard icon - that there are NO URL encoding of slashes to %2F. Yet in Storage Explorer %2F ---

The storage account is being accessed using normal RBAC via Storage Explorer and not a SAS.
The type is StorageV2 (general purpose v2)

https://ACCOUNT.blob.core.windows.net/slbdrops/slb-curl%2Fcurl-build_22_20200506_101%2Fcurl-build.zip

image

@craxal
Copy link
Contributor Author

craxal commented May 6, 2020

The URL comes from the Azure Node client library, and we updated to v12 between Storage Explorer 1.12.0 and 1.13.0. We'll need to get in touch with them and find out why the URL behavior is different in v12 than in previous versions.

@jasongaylord
Copy link

The URL comes from the Azure Node client library, and we updated to v12 between Storage Explorer 1.12.0 and 1.13.0. We'll need to get in touch with them and find out why the URL behavior is different in v12 than in previous versions.

Glad it has been identified. It's a big pain.

@egdedudette
Copy link

Any news on this?

@craxal
Copy link
Contributor Author

craxal commented May 12, 2020

According to @XiaoningLiu, this was an intentional change on the part of the client SDK. See Azure/azure-sdk-for-js#6886 for reference.

@egdedudette We understand the inconvenience this problem has caused, and we're working on a solution. We will need some time to run tests to make sure we don't break anything, because a lot of different parts rely on the code where the URL comes from.

@jasongaylord As a workaround, are you able to replace the %2F encodings with slashes manually and get a working URL?

@JasonYeMSFT JasonYeMSFT self-assigned this May 13, 2020
@JasonYeMSFT JasonYeMSFT added the 🪲 regression Issue was working in a previous version label May 13, 2020
@JasonYeMSFT JasonYeMSFT added this to Committed in Storage Explorer via automation May 13, 2020
@JasonYeMSFT JasonYeMSFT added this to the 1.14.0 milestone May 13, 2020
@jasongaylord
Copy link

@craxal For now, that's what I've been doing. When I drop a bunch of blobs, it's somewhat time consuming, but it works for now.

@craxal craxal modified the milestones: 1.14.0, 1.13.1 May 13, 2020
@craxal
Copy link
Contributor Author

craxal commented May 13, 2020

@jasongaylord Thanks. Just wanted to make sure you had a workaround while we're working on a solution.

@JasonYeMSFT JasonYeMSFT moved this from Committed to Done in Storage Explorer May 18, 2020
@JasonYeMSFT JasonYeMSFT added the ✅ merged A fix for this issue has been merged label May 18, 2020
@jasongaylord
Copy link

@JasonYeMSFT I didn't notice anything in the build version. Is it closed because its in an Insider build?

@JasonYeMSFT
Copy link
Contributor

We are making an 1.13.1 release which contains a fix for this issue. It is being propagated to the data centers and should be available soon.

@jinglouMSFT
Copy link

@jasongaylord you can download 1.13.1 from the "Releases" tab in this repo. We just released the bits there. If you prefer being prompted to upgrade, you will need to wait for at least another day for the bits on Microsoft download center to be propagated to all data centers before you see the prompt.

@jasongaylord
Copy link

Thanks @JasonYeMSFT and @jinglouMSFT! I blogged about it. Should be posted by early morning. Appreciate the quick turnaround.

@jasongaylord
Copy link

FWIW, version 1.13.1 has not yet propagated. I'm going to get it from the releases tab.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🪲 regression Issue was working in a previous version ✅ merged A fix for this issue has been merged
Projects
Development

No branches or pull requests

6 participants