-
Notifications
You must be signed in to change notification settings - Fork 971
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
Storage Emulator does not match Google Cloud Storage library API #3953
Comments
Just an addendum to the above problem.
The library is also non-compliant (or perhaps not accommodating) of handling the multipart/related which I imagine would cause a whole bunch of issues for any non-Firebase GCS client library trying to access the emulator using their multipart/related code. A couple of case in points BoundariesThe emulator assumes the boundary value from Content-Type doesn't have double quotes around the value... which for a number of libraries (and again spec). These are valid
So this bit of code won't work
Blob HeadersNext is how the handler handles the looking for its content-type
HTTP Headers are not case sensitive... so the startsWith (nor the slice) can't be used here as below is valid and would never be found
Anyway I'm sure Storage Emulator is in early days and it will improve but at this stage it feels that using it with other GCS Client libraries is not looking good. Perhaps formidable or Multer or Multiparty might be more suitable for the task. |
Just putting some code here until it is fixed. Maybe it'll help... I can't guarantee performance or meeting every spec (multipart is complicated)
|
So this is actually out of scope for the Cloud Storage for Firebase emulator since our goal is only to cover the Firebase SDKs and the Cloud SDKs which get exposed through It looks like you've done a lot of work on this and we'd happily review a PR with any changes if you had time! |
Hi is there anything else you'd like done here for this? I noted your comment but I think it may fall within the scope of the emulator because the Firebase Admin SDK actually makes use of the default Google Cloud Storage client library to interact with the Firebase Storage emulator ... (at least in the Python stack). |
Hi @kenttregenza, thanks for the PR and apologies for the lack of communication. I'll be taking over this issue as @abeisgoat has left Firebase. Can you please rebase your PR off master as unfortunately a lot has changed since you originally authored it. Can you also split the change into two separate PRs for us to review: one for the multipart changes and one for the name compatibility. I appreciate your patience and your contribution! |
Hopefully there is more movement on this, might resolve googleapis/python-storage issue 752, which I created before finding this issue / PR. |
Wanted to +1 as I'm also encountering the described issues. |
Filed internal bugs to track to 3 feature requests above, b/240630224, b/240637637, b/240627424 |
@kenttregenza |
[REQUIRED] Environment info
firebase-tools:
9.23.0
Platform:
Windows 10
[REQUIRED] Test case
Using the Google Cloud Storage Python library which follows the Google Cloud Storage JSON API spec upload a file
[REQUIRED] Steps to reproduce
Any GCS Client library which puts name inside the body of the "file" metadata of the upload and doesn't put name as a query parameter. (Again as per Google Cloud Storage JSON API spec upload a file)
[REQUIRED] Expected behavior
The emulator should get the name of the file from the metadata passed by the client library. Then the file should be uploaded and file metadata returned in a 200 response.
[REQUIRED] Actual behavior
Returns 400 because name is not found in the query (even though name is in the metadata)
The Problem
The problems stems from the emulator/storage/apis/gcloud.js implementation
The POST handler is checking for a name parameter but the spec says it is optional and may be instead passed via metadata which is in the metadata section of a multipart upload or in the body for a resumable upload.
I just thought it might be worthy of fixing.
The text was updated successfully, but these errors were encountered: