-
Notifications
You must be signed in to change notification settings - Fork 213
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
Content-Type being set incorrectly for resumable uploads. #1098
Comments
I'm not sure if the issue is fixed by that PR, looking at it I don't think I see how. It ended-up getting closed automatically due to a comment in the PR body. I still plan to have a deeper look at this issue some time in the next couple of weeks. |
Awesome, thank you! Looking forward to the fix 😄 |
Thank you for this fantastic test tool! I just ran into this issue, us using the node client libraries. Creating a file with the "blob.createWriteStream" API, tests with explicit contentType failed as it always came back as "application/octet-stream", something that appears to be the default in upload.go if Content-Type header is missing. I have verified that resumable is also the cause here, and if I put { resumable: false } into the createWriteStream-options, it works as it should. Setting this flag is probably ok as a workaround, especially as Google says it should be set to false for files smaller than 10MB, but presumably this means that it should be on for larger files. I'm testing using 1.49.3 |
Thanks for the workaround @larsivi. I can confirm that this fixed the issue in our case, also on 1.49.3. |
Hi!
First of all, thank you for developing this. It's an invaluable tool for local development :)
We are using the latest version (
1.44.0
) with Ruby/Rails where the Google SDK always does resumable uploads.Generally, it's working well but the content type of all uploaded files is set to
application/json
. This can be verified byexec
ing into the Docker container and runningattr
(might have toapk --update add
it first) on the file.Now this happens regardless of whether
content_type
is added to the original upload. Here is the output of the SDK with nocontent_type
parameter. As you can see, nocontent_type
is present in the initial upload, but the actual uploaded file ends up with a content type ofapplication/json
.Now, as I mentioned, this even happens when you pass the correct
content_type
to the upload command.If we restart the GCS server and it reloads the files from disk, the content type is set correctly (again, can be verified by running
attr
on the file as well). I assume this is because of #531.It would however be great if the content type would also be correct for newly uploaded files, when using resumable uploads!
It looks like this was addressed in #532 and supposedly fixed in #924 but it does not seem to be working.
I also tried passing in the
ContentType
viametadata
, according to the fix mentioned here: #924.As you can see, the metadata is even saved correctly, but the actual
ContentType
is still set toapplication/json
.The text was updated successfully, but these errors were encountered: