Thanks for pointing this out. It looks like we have support for IfGenerationMatch and IfMetagenerationMatch in this library, but not If-Match/If-None-Match.

One likely reason is that it looks like If-Match and If-None-Match are only supported via the XML API, while this library uses the JSON API for most operations. (e.g. see https://cloud.google.com/storage/docs/json_api/v1/objects/insert#parameters which only includes the generation and metageneration headers). Reads are the main operation that actually do use XML currently but I'm hesitant to add support for a feature that's not present in JSON at all.

@frankyn any more thoughts on this, or suggestions for how to work around this gap?

Look at the documentation I pointed out in the issue's description. It states that If-Match/If-None-Match are supported by the JSON API (But not If-Modified-Since/If-Unmodified-Since?). The request headers are just documented on other pages and not on every request like the documentation of the XML API, leading to this confusion.

Ah I see that it is present here: https://cloud.google.com/storage/docs/json_api/v1/parameters#ifmatch . Sorry I was confused about that. And indeed it looks like If-Modified-Since and In-Unmodified-Since are not present.

I'll follow up internally to see if there's any reason we shouldn't look into adding support. In the mean time, it is possible in this library to add arbitrary headers to a request by wrapping the HTTP transport and using the WithHTTPClient option, though it's a bit clunky to execute this. Let me know if you'd like a code snippet for how to do this workaround.

Hi @segevfiner,

Do you have more background on your use-case and if GCS Generation (ifGenerationMatch) and Metageneration (IfMetaGenerationMatch) preconditions would be enough in this case?

@tritone is following up with the GCS backend team to get information on if Etag (If-Match/If-None-Match) should also be discouraged in libraries. We try to follow public documentation in most cases but it's not super clear if there are any reasons anyone would want to use them.

Side note: I saw a similar issue in java-storage: googleapis/java-storage#628

My use case is supporting HTTP conditional requests when serving objects from a bucket by an HTTP web server implemented in Go. This boils down to forwarding and returning the relevant headers to the object/blob store and the requesting client.

I'm using the gocloud.dev/blob package and originally asked for this there, where I discovered that this is supported by the other cloud object/blob stores, and their libraries, but not by the GCS Go library, and that it is documented that in GCS (implicitly by it being omitted) that it doesn't support If-Modified-Since & If-Unmodified-Since.

Generation and metageneration obviously won't help here, the browsers don't know about those things and require the standard HTTP headers like ETag, If-None-Match, etc.

Another thing is that passing/retrieving such headers is also interesting for HEAD HTTP requests, not sure how those are exposed in the client.

We don't support HEAD requests specifically in the client. If you want to access metadata for example, we provide the Object.Attrs and Bucket.Attrs surfaces.