Signing file with leading slash using getSignedUrl results in double slash

[emielvanliere]

Environment details

• OS: MacOS
• Node.js version:10.15.0
• npm version:6.13.0
• @google-cloud/storage version: 4.1.2 (as part of firebase-admin-node 8.8.0)

Steps to reproduce

After upgrading to firebase-admin-node 8.8.0, which updates @google-cloud/storage version to 4.1.2 I'm experiencing an issue signing files/paths that start with a slash.

Reproduce:

const bucketName = "my_bucket";
const file = "/file.jpg";
const bucket = firebase.storage().bucket(bucketName);
const getSignedUrls = await bucket.file(file).getSignedUrl({action:"read"});
const signedUrl = getSignedUrls[0];

signedUrl will now be https://storage.googleapis.com/my_bucket//file.jpg?<signature> instead of https://storage.googleapis.com/my_bucket/file.jpg?<signature>. Notice the dobule slash in the first url; files with a double slash in the url are not accessible on cloud storage.

I would expect files that start with a slash to reference the root of the bucket (as an absolute path), and I would not expect the library to insert an extra slash.

This is probably related to the change in: #820

[stephenplusplus]

We can still work this out, and maybe the right thing to do is trim a single leading slash. On the other hand, I think if we take the upstream Storage API literally, the remote object name is not “/file.jpg”, it’s “file.jpg”. Accordingly, that’s what we expect from our File accessor method— whatever is consistent with the remote representation should be the least surprising.

[dmitry-fa]

'/file.jpg' and 'file.jpg' are different objects, therefore they should be referred by different URLs
https://storage.googleapis.com/my_bucket//file.jpg?<signature> will refer to the first one
when https://storage.googleapis.com/my_bucket/file.jpg?<signature> to the second

According to [1] there is no restriction on using '/' in the object names. Moreover, 'Object names reside in a flat namespace within a bucket. This means that: Objects do not reside within subdirectories in a bucket'. It means that '//' and '///' are valid object names.

The way how '/' could be interpreted is described in [2]:
gsutil provides the illusion of a hierarchical file tree atop the "flat" name space supported by the Cloud Storage service.

[1] https://cloud.google.com/storage/docs/naming
[2] https://cloud.google.com/storage/docs/gsutil/addlhelp/HowSubdirectoriesWork

[stephenplusplus]

I'm going to close for now, but if anyone has objections, let's keep figuring it out.