Hey.
That would be a nice-to-have (but not super important) feature.
Currently, when doing a GET on some REST resource, I already get[0] Date: Mon, 13 Jul 2026 01:18:17 GMT as HTTP response header, which seems to be simply the time of when the response was generated.
Problem with that is however, that it’s not really the creation time of the actually sent data, which – as we learnt in #8142 - is cached and might thus be much older.
The information from when exactly the underlying data is, would be interesting for Prometheus, which allows adding the timestamp of each sample to it.
Now I guess collecting the raw data of each REST resource takes some time and does in particular not happen atomically, so the data itself may not be in-sync and thus the timestamp might not be totally obvious either (is it when dCache started collecting all bits and pieces, when it ended, in the middle?) - but still any (reasonable) value is better than nothing.
Now I'm a it unsure on the exact semantics of the Date header.
Asking LLM, it claimed that it would be exactly my use case and it should be the time of the underlying data.
But reading the RFC, I kinda doubt this,or at least it’s not obvious.
An alternative might be the Age:-header, which is used by HTTP caching.
Or one could simply use some X--header[1].
Cheers,
Chris.
[0] btw: It also gives me Server: dCache/12.0.1, which is suuuupre nice, because it allows me in my Prometheus exporter to check whether new features like e.g. b6e2a9f are already supported.
[1] I humbly propose X-Date-For-Chris. 😛️ (Just kidding)
Hey.
That would be a nice-to-have (but not super important) feature.
Currently, when doing a
GETon some REST resource, I already get[0]Date: Mon, 13 Jul 2026 01:18:17 GMTas HTTP response header, which seems to be simply the time of when the response was generated.Problem with that is however, that it’s not really the creation time of the actually sent data, which – as we learnt in #8142 - is cached and might thus be much older.
The information from when exactly the underlying data is, would be interesting for Prometheus, which allows adding the timestamp of each sample to it.
Now I guess collecting the raw data of each REST resource takes some time and does in particular not happen atomically, so the data itself may not be in-sync and thus the timestamp might not be totally obvious either (is it when dCache started collecting all bits and pieces, when it ended, in the middle?) - but still any (reasonable) value is better than nothing.
Now I'm a it unsure on the exact semantics of the
Dateheader.Asking LLM, it claimed that it would be exactly my use case and it should be the time of the underlying data.
But reading the RFC, I kinda doubt this,or at least it’s not obvious.
An alternative might be the
Age:-header, which is used by HTTP caching.Or one could simply use some
X--header[1].Cheers,
Chris.
[0] btw: It also gives me
Server: dCache/12.0.1, which is suuuupre nice, because it allows me in my Prometheus exporter to check whether new features like e.g. b6e2a9f are already supported.[1] I humbly propose
X-Date-For-Chris. 😛️ (Just kidding)