[GH-ISSUE #2102] Object metadata not preserved (Cache-Control, Content-Encoding, Content-Disposition, custom metadata) #252

New issue

Closed

opened 2026-03-03 12:09:26 +03:00 by kerem · 1 comment

kerem commented

2026-03-03 12:09:26 +03:00

Owner

Originally created by @louisnow on GitHub (Jan 3, 2026).
Original GitHub issue: https://github.com/fsouza/fake-gcs-server/issues/2102

Object metadata set during upload is lost and returns null when retrieving objects. This happens for both simple uploads and multipart uploads.

What's broken

When uploading with metadata like:

BlobInfo.newBuilder(bucket, name)
    .setCacheControl("max-age=3600")
    .setContentEncoding("gzip")
    .setContentDisposition("attachment; filename=doc.pdf")
    .setMetadata(Map.of("owner", "user123"))
    .build();

All these values come back as null on subsequent GET requests.

Why this matters for us

We're using fake-gcs-server to test S3Proxy's new native GCS SDK backend (google-cloud-storage-sdk). S3Proxy translates S3 API calls to GCS, so we need metadata to round-trip correctly.

Without this, we can't verify that:

S3 Cache-Control headers survive the S3 -> GCS -> S3 translation
Multipart uploads preserve the metadata set during InitiateMultipartUpload
Content-Disposition for downloads works correctly
Custom S3 user metadata (x-amz-meta-*) maps to GCS metadata properly

We've had to skip these assertions in our test suite when running against fake-gcs-server, which means less confidence in local testing before hitting real GCS.

Tested with

fsouza/fake-gcs-server:latest with -scheme http on port 4443
Google Cloud Storage Java SDK 2.x.x

All these tests pass against real GCS, so the issue is specific to fake-gcs-server.

Originally created by @louisnow on GitHub (Jan 3, 2026). Original GitHub issue: https://github.com/fsouza/fake-gcs-server/issues/2102 Object metadata set during upload is lost and returns `null` when retrieving objects. This happens for both simple uploads and multipart uploads. ## What's broken When uploading with metadata like: ```java BlobInfo.newBuilder(bucket, name) .setCacheControl("max-age=3600") .setContentEncoding("gzip") .setContentDisposition("attachment; filename=doc.pdf") .setMetadata(Map.of("owner", "user123")) .build(); ``` All these values come back as `null` on subsequent GET requests. ## Why this matters for us We're using fake-gcs-server to test [S3Proxy](https://github.com/gaul/s3proxy)'s new native GCS SDK backend (`google-cloud-storage-sdk`). S3Proxy translates S3 API calls to GCS, so we need metadata to round-trip correctly. Without this, we can't verify that: - S3 `Cache-Control` headers survive the S3 -> GCS -> S3 translation - Multipart uploads preserve the metadata set during `InitiateMultipartUpload` - `Content-Disposition` for downloads works correctly - Custom S3 user metadata (`x-amz-meta-*`) maps to GCS metadata properly We've had to skip these assertions in our test suite when running against fake-gcs-server, which means less confidence in local testing before hitting real GCS. ## Tested with - `fsouza/fake-gcs-server:latest` with `-scheme http` on port 4443 - Google Cloud Storage Java SDK 2.x.x All these tests pass against real GCS, so the issue is specific to fake-gcs-server.

kerem closed this issue

2026-03-03 12:09:26 +03:00

kerem commented

2026-03-03 12:09:27 +03:00

Author

Owner

@louisnow commented on GitHub (Jan 3, 2026):

@fsouza I've made a fix for it using claude code. I've reviewed it and what the AI has produced is similar to what I would have written but slower and only half as comprehensive

https://github.com/fsouza/fake-gcs-server/pull/2103

@louisnow commented on GitHub (Jan 3, 2026): @fsouza I've made a fix for it using claude code. I've reviewed it and what the AI has produced is similar to what I would have written but slower and only half as comprehensive https://github.com/fsouza/fake-gcs-server/pull/2103

kerem referenced this issue

2026-03-03 12:30:07 +03:00

[PR #252] [MERGED] build(deps): bump google.golang.org/api from 0.24.0 to 0.25.0 #458