[PR #1141] [MERGED] Propagate ContentType field on create/modify ops #1228

New issue

Closed

opened 2026-03-03 12:33:39 +03:00 by kerem · 0 comments

kerem commented

2026-03-03 12:33:39 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/fsouza/fake-gcs-server/pull/1141
Author: @alorlea
Created: 4/27/2023
Status: ✅ Merged
Merged: 5/2/2023
Merged by: @fsouza

Base: main ← Head: propagate-content-type-changes-to-blobs

📝 Commits (3)

63851ca Propagate ContentType field on create/modify ops
0898af6 Test for updateObject with content type
e823414 Update fakestorage/object_test.go

📊 Changes

3 files changed (+62 additions, -5 deletions)

View changed files

📝 fakestorage/object.go (+5 -4)
📝 fakestorage/object_test.go (+51 -0)
📝 fakestorage/upload.go (+6 -1)

📄 Description

This PR tries to address 2 bugs that where found when using some of the create/modify operations GCS supports in our integration tests that used the following interactions:

Rely on a streamable upload operations of GCS to upload of a File.
Submit an update on the blob to override the metadata content-type information without modifying the bytes of the blob.

To crosscheck, we ran the same tests against the real GCS API to verify the behaviour to expect:

Streamable upload, by default if no content-type is provided; GCS sets it up to 'application/octet-stream' or uses the one provided by the user in the BlobInfo (This is the expected behaviour for this operation in GCS).
For an update, when we merge metadata information regarding the content-type, it should override and reflect the change on the update response.

Also this behaviour is referenced on the API spec, that the content-type should be set to application/octet-stream on object creation if it is not defined:

Also should hopefully address the following issue https://github.com/fsouza/fake-gcs-server/issues/1098 🙂

Fixes #1098.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/fsouza/fake-gcs-server/pull/1141 **Author:** [@alorlea](https://github.com/alorlea) **Created:** 4/27/2023 **Status:** ✅ Merged **Merged:** 5/2/2023 **Merged by:** [@fsouza](https://github.com/fsouza) **Base:** `main` ← **Head:** `propagate-content-type-changes-to-blobs` --- ### 📝 Commits (3) - [`63851ca`](https://github.com/fsouza/fake-gcs-server/commit/63851ca363ea5ba11bcbbadb2a0c1fe437bf7f10) Propagate ContentType field on create/modify ops - [`0898af6`](https://github.com/fsouza/fake-gcs-server/commit/0898af6d9fbeceece4c0796b99bd559f649fceed) Test for updateObject with content type - [`e823414`](https://github.com/fsouza/fake-gcs-server/commit/e823414f29c1752738a0a1a45ef975822a938a95) Update fakestorage/object_test.go ### 📊 Changes **3 files changed** (+62 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `fakestorage/object.go` (+5 -4) 📝 `fakestorage/object_test.go` (+51 -0) 📝 `fakestorage/upload.go` (+6 -1) </details> ### 📄 Description This PR tries to address 2 bugs that where found when using some of the create/modify operations GCS supports in our integration tests that used the following interactions: * Rely on a streamable upload operations of GCS to upload of a File. * Submit an update on the blob to override the metadata content-type information without modifying the bytes of the blob. To crosscheck, we ran the same tests against the real GCS API to verify the behaviour to expect: 1. Streamable upload, by default if no `content-type `is provided; GCS sets it up to` 'application/octet-stream'` or uses the one provided by the user in the BlobInfo (This is the expected behaviour for this operation in GCS). 2. For an update, when we merge metadata information regarding the content-type, it should override and reflect the change on the update response. Also this behaviour is referenced on the API spec, that the `content-type` should be set to `application/octet-stream` on object creation if it is not defined: 1. [GCS Insert Request Body](https://cloud.google.com/storage/docs/json_api/v1/objects/insert#request-body) 2. [GCS Update Request Body](https://cloud.google.com/storage/docs/json_api/v1/objects/update#request-body) Also should hopefully address the following issue https://github.com/fsouza/fake-gcs-server/issues/1098 :slightly_smiling_face: Fixes #1098. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>