Google-cloud-node: 200 in development, 404 in production

[sabrehagen]

Environment details

• OS: Alpine 3.4
• Node.js version: 8.1.3
• npm version: 5.0.3
• google-cloud-node version: latest

In development the application is containerised with the above configuration. In production the app is running the same container on GKE.

Symptoms

Running the same user-land code of storage.createReadStream('a5bfd28d-b914-497e-91d5-33d9fd43e47f.png') in development and production produces different results.

In development, the call above requests the url

https://storage.googleapis.com/stemn/uploads%2Fa5bfd28d-b914-497e-91d5-33d9fd43e47f.png

and the storage resource is found correctly. In production, the same call requests the url

https://www.googleapis.com/storage/v1/b/stemn/o/%2Fuploads%2Fa5bfd28d-b914-497e-91d5-33d9fd43e47f.png?alt=media

which 404s.

I'm not sure what's causing the structure of these urls to be different. Could you suggest steps that I could take that would provide you more information about this issue?

[stephenplusplus]

The second URL structure is new in the latest release of the @google-cloud/storage module. You can replicate it locally by upgrading. The problem seems to be a leading slash in the image resource name. Could you double check that your code looks like "bucket.file('uploads/...')" and not "bucket.file('/uploads/...')"?

[sabrehagen]

Hi, thanks for pointing out the version differences. That would explain the different functionality - doh! I've removed preceding slashes from all paths and my code is working as expected. This change might catch out many users like me who relied on this functionality previously. Should the library be modified to strip preceding slashes?

[stephenplusplus]

I agree, we should do that. And we actually tried to in #2269! Looks like we overlooked a code path, and ended up without a full fix. I'll PR it!

[stephenplusplus]

PR sent in #2470 -- sorry for the delay!