Question

The Google Cloud Storage Developer Guide explains how to set Cache-Control headers, and explains their critical impact on the consistency behavior of the api, yet the Expires headers aren’t mentioned nor did they appear to be inheriting from the Cache-Control configuration.

The Expires header appeared to always be equal to request time plus 1 year, regardless of Cache-Control setting, eg.

$ gsutil setmeta -h "Cache-Control:300" gs://example-bucket/doc.html 

A request was made to a document (doc.html) in the Google Cloud Storage bucket (example-bucket) via

$ curl -I http://example-bucket.storage.googleapis.com/doc.html

which produced the following headers

HTTP/1.1 200 OK
Server: HTTP Upload Server Built on Oct 3 2012 16:52:30 (1349308350)
Date: Sat, 13 Oct 2012 00:51:13 GMT
Cache-Control: 300, no-transform
Expires: Sun, 13 Oct 2013 00:51:13 GMT
Last-Modified: Fri, 12 Oct 2012 20:08:41 GMT
ETag: "28fafe4213ae34c7d3ebf9ac5a6aade8"
x-goog-sequence-number: 82
x-goog-generation: 1347601001449082
x-goog-metageneration: 1
Content-Type: text/html
Accept-Ranges: bytes
Content-Length: 7069
Vary: Origin

Answer 1

Not sure why you say the Expires header shows request time plus 1 year. In your example, the Expires header shows a timestamp one hour after the request date, which is to be expected.

I just did an experiment where I set an object’s max age to 3600 and then 7200 via this command:

gsutil setmeta "Cache-Control:max-age=7200" gs://marc-us/xyz.txt

Then I retrieved the object using the gsutil cat command with the -D option to see the request/response details, like this:

gsutil -D cat gs://marc-us/xyz.txt

In both experiments, the Expires header produced the expected timestamp, as per the object’s max-age setting (i.e. one hour after request time and two hours after request time).