Is it possible to store the timestamp for such entries?

I don't know. Does the time come from the server's original HTTP header?
Either the current time (of insert), or a dash or other indicator of unknown would probably be more helpful than an obviously bugged time of 0.

The cache preview is a great addition to devtools, but it can't handle synthetic Responses at all, even with the correct content-type header set.

Chasing it back a fair bit (but not all the way...), it looks like an internal timestamp corresponding to when the headers were received; not necessarily the time given in the headers. 

Since this isn't a property exposed via the Response interface, I think we can do whatever we want here for synthetic responses. One of the Response::Create() overloads could call r->response_->SetResponseTime(WTF::Time::Now()) (fetch API experts?)

Showing "N/A" or "--" seems like a plausible approach too.

Could the "Time Cached" field simply show the value of the "Last-Modified" response header, if present?

The interface has changed significantly since I filed this, but still has major rough edges.

The problem with reliance on headers is it shows 0 bytes when there’s no ‘content-length’ header. 
However cache entries may not be fully formed responses themselves, rather lumps of template and so on. Shouldn’t devtools have a privileged view of the cache and know the actual number of bytes?

Also the path doesn’t show query string parameters. You have to manually click though entries to examine these.
And the dark theme doesn’t have a color for the binary data preview. It’s currently black on dark grey.

Deleted: devtools.png 20.9 KB

	devtools.png 20.9 KB View Download

 Issue 845629  has been merged into this issue.

Gentle ping on this one. Having this working would make it a little easier to debug issues with service workers. Speaking only for myself, either sourcing the value from a header or using the time when Response::Create() was called would be fine; any information would be much better than none.

Eugene, I'm going to go ahead and steal this bug.  Please feel free to take it back if you are working on it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/834841e45aa3189a208b49d548050c18bdcb6cb3

commit 834841e45aa3189a208b49d548050c18bdcb6cb3
Author: Ben Kelly <wanderview@chromium.org>
Date: Tue Oct 02 00:38:03 2018

Make default ResponseTime the time when the Response was created.

This CL sets a default ResponseTime when a Response object is created.  This
will be overriden with the real ResponseTime when created via fetch() or Cache
API.  Synthetic Response objects created using the constructor, however, will
end up using this default value for their ResponseTime.

Bug:  747718 
Change-Id: Id8c56c875d6ca00285048ebd51f92c0380dcfed1
Reviewed-on: https://chromium-review.googlesource.com/1255423
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Commit-Queue: Ben Kelly <wanderview@chromium.org>
Cr-Commit-Position: refs/heads/master@{#595665}
[modify] https://crrev.com/834841e45aa3189a208b49d548050c18bdcb6cb3/third_party/blink/renderer/core/fetch/fetch_response_data.cc
[modify] https://crrev.com/834841e45aa3189a208b49d548050c18bdcb6cb3/third_party/blink/renderer/core/fetch/fetch_response_data_test.cc