[GH-ISSUE #1967] Reumable uploads lose preconditions #236

New issue

Open

opened 2026-03-03 12:09:21 +03:00 by kerem · 0 comments

kerem commented

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

Owner

Originally created by @patricklucas on GitHub (May 17, 2025).
Original GitHub issue: https://github.com/fsouza/fake-gcs-server/issues/1967

Supported preconditions such as ifGenerationMatch do not get enforced for resumable uploads, as they are (correctly) not checked on the initial request to create the upload object, and are not passed to createObject upon commit.

Looking into the behavior of the GCS Java SDK, I found that the behavior is that the server, in response to the POST to create the upload, includes the original preconditions in the query string of the returned location, and the client includes them on the subsequent PUTs.

That's fairly easily done here as well, including them here. I've tested this and it works as expected, with resumable uploads to an existing object that include ifGenerationMatch=0 fail with code 412.

Originally created by @patricklucas on GitHub (May 17, 2025). Original GitHub issue: https://github.com/fsouza/fake-gcs-server/issues/1967 Supported preconditions such as `ifGenerationMatch` do not get enforced for resumable uploads, as they are (correctly) not checked on the initial request to create the upload object, and are not passed to `createObject` upon commit. Looking into the behavior of the GCS Java SDK, I found that the behavior is that the server, in response to the POST to create the upload, includes the original preconditions in the query string of the returned location, and the client includes them on the subsequent PUTs. That's fairly easily done here as well, including them [here](https://github.com/fsouza/fake-gcs-server/blob/v1.52.2/fakestorage/upload.go#L450). I've tested this and it works as expected, with resumable uploads to an existing object that include `ifGenerationMatch=0` fail with code 412.