I have also verified this issue on android. Chrome version 55.0.2883.91

I tried to reproduce the problem on Chrome for Android 55.0.2883.91 and Linux 55.0.2883.87 (64-bit). In both cases, the 'Expires' header is respected and the page is updated only once every 15 seconds when the 'Revisit' link is clicked. Does the problem still exist?

Yes. I have also tried with multiple devices, and the issue is reproducible only on some devices. I will try and upload a video tonight and the tcpdump if possible.

Rather than a tcpdump, can you go to about://net-export on your android device and attach the resulting log to the bug?

Thanks!

Thank you for providing more feedback. Adding requester "kapishnikov@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Please provide the netlog as mentioned in comment #5 from a device that has this issue. You can find the instructions here: https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details
Thanks!

Hello, sorry for the late reply. PFA the required netlog. I have reproduced the issue on desktop version 55.0.2883.87.

Deleted: net-internals-log.json 201 KB

net-internals-log.json 201 KB View Download

Hrm...That log does indeed show us going over the network for requests less than 15 seconds apart.  The page works fine for me, however.

Maybe this is a case of clock skew?  Your local clock is 3 minutes ahead of the server clock, though I thought our cache logic handled that sort of clock skew.  I'll defer to people who know the cache code.

It can be seen that a new cache entry is created every time the http://spe.mobilephone.net/wit/commonv1/httpcacheexp1.xhtml URL is retrieved. However, for some reason, the cache matching logic for the subsequent requests cannot match the previously added cache entry, even though the entry is found and the requests are made within the 'Expires' time. As the result, the URL is repeatedly re-fetched and new cache entries are created.

It would be great if the netlog had the info why the entry wasn't matched.

Added TE-NeedsTriageHelp as it can't be triaged from TE end.

Thanks for the netlog. Do you happen to have devtools open when you're visiting the page? If so, do you have "disable cache" checked in the networking tab? That would cause this behavior.

Your welcome. No, devtools isn't open when visiting the page. 

Good eye Matt. This is WAI (or at least, working as spec intended).

I set my clock forward an hour and I'm able to reproduce. When calculating the age of a resource, the local clock and server clock are expected to be synchronized. See RFC 2616 13.2.3 Age Calculations. 

Firefox has the same behavior.

Reopening this because the spec bothers me. Why does it require the client and server to be synchronized? There must be a good reason but I'm not sure what it is.

> Why does it require the client and server to be synchronized?
As far as I understood, the age calculation algorithm depends on two things
1. The value of the Date header set by the origin server and
2. The response time as calculated by the client.
If these two timings aren't synchronized, it'll lead to a wrong calculation of the age of the cached resource.

There is one more parameter considered for age calculation which is the Age header. According to RFC 7234 section 4.2.3, if all the hops between the origin server and the client implement HTTP 1.1 we can directly use this value for age computation. This value(corrected_age_value) isn't subject to clock skew
(response_delay = response_time - request_time;
 corrected_age_value = age_value + response_delay;) 
because both response_time and request_time are measured at the same client.

Though I am not sure how to verify if all the hops implement HTTP 1.1. The Via header field might help. What do you think?

Right, but we could ignore the date header and just use the current_time - response_time. Then the clocks wouldn't need to be synchronized.

I didn't quite follow you.
current_time - response_time would give us the time that the resource was in the client side cache and not the overall age of the resource.

Consider an eg.
Date = Fri, 20 Jan 2011 10:50:14
request_time = Fri, 20 Jan 2011 10:40:08 GMT
response_time = Fri, 20 Jan 2011 10:40:12 GMT
current_time = Fri, 20 Jan 2011 10:40:14 GMT
Age = 2

If you just use
current_time - response_time 
the age would be 2s,
whereas the age would actually be 8s

If you meant dropping the Date header and relying on the Age header, we should have all HTTP 1.1 hops since HTTP 1.0 doesn't support the Age header AFAIK.

I was suggesting that the user agent ignore date and only consider current_time - response_time + Age. I agree that this is a breaking change. It just seems silly that the protocol requires the client and server to have synchronized clocks.

Closing as I'm not going to get a chance to follow up on spec discussion here.