False-positive cache-control records in report

I’m observing discrepancy in my reports specific to cache-control response headers.
Some resources are listed as “FAILED - (No max-age or expires)” in Cache section of the report, but I do see this header displayed in Details section for the given sub-request
Sample report:

Following resource is listed as “FAILED - (No max-age or expires)”:

FAILED - (No max-age or expires) - https://www.toyota.com/imgix/content/homepage/img/explore/ToyotaRacing.png?w=552&dpr=1&q=80&fm=jpg&lossless=false&fit=max&cs=strip&bg=fff&

But here is what is listed in the Details section:

[code]Request 11: https://www.toyota.com/imgix/content/homepage/img/explore/ToyotaRacing.png?w=552&dpr=1&q=80&fm=jpg&lossless=false&fit=max&cs=strip&bg=fff&
URL: https://www.toyota.com/imgix/content/homepage/img/explore/ToyotaRacing.png?w=552&dpr=1&q=80&fm=jpg&lossless=false&fit=max&cs=strip&bg=fff&
Host: www.toyota.com
Error/Status Code: 200
Priority: Low
Protocol: HTTP/2
HTTP/2 Stream: 21, weight 147, depends on 19, EXCLUSIVE
Initiated By: https://www.toyota.com/?removeEnsighten=true line 2202
Client Port: 65068
Request Start: 1.060 s
Time to First Byte: 79 ms
Content Download: 27 ms
Bytes In (downloaded): 36.3 KB
Uncompressed Size: 35.9 KB
Bytes Out (uploaded): 0.1 KB
Request Headers:

:method: GET
:authority: www.toyota.com
:scheme: https
:path: /imgix/content/homepage/img/explore/ToyotaRacing.png?w=552&dpr=1&q=80&fm=jpg&lossless=false&fit=max&cs=strip&bg=fff&
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36 PTST/396
accept: image/webp,image/apng,image/,/*;q=0.8
referer: https://www.toyota.com/?removeEnsighten=true
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.8
Response Headers:

:status: 200
content-type: image/jpeg
content-length: 36802
cache-control: public,max-age=604800
last-modified: Tue, 26 Sep 2017 17:10:51 GMT
server: imgix-fe
accept-ranges: bytes
date: Wed, 11 Oct 2017 22:09:11 GMT
x-content-type-options: nosniff
x-served-by: cache-lax8626-LAX, cache-iad2123-IAD
age: 1028091
x-cache: Hit from cloudfront
via: 1.1 cf6dfc066230dcf69540e8c3f8d6f9de.cloudfront.net (CloudFront)
x-amz-cf-id: K-rD5hX3vwu8Xtvf-m3qeBUZxesQxKPwAJe0UFl7uoJ-hKuXRnF3sw==

There are like ten resources like this listed in that report.

Please help me to interpret results properly. What is actually wrong with it?

I do see your confusion, as I can verify the response headers on those images are “cache-control: public,max-age=604800”

One thing to try is to do a repeat-view test. When you do that, is the image actually re-downloaded again? If so, then there must be something off in the cloudfront settings. If not, then perhaps this is a bug within WPT.

Thank you for responding! That was very good suggestion. Luckily, that run was configured to hit on First view and the Repeat view, so I checked it out, and… the http response code was 304 - definitely cached :slight_smile:

:status: 304 date: Mon, 16 Oct 2017 20:46:19 GMT cache-control: public,max-age=604800 server: imgix-fe x-content-type-options: nosniff x-served-by: cache-lax8626-LAX, cache-iad2123-IAD age: 1028111 x-cache: Hit from cloudfront via: 1.1 98dbec6ba78c561cf37410a3bbd19a4e.cloudfront.net (CloudFront) x-amz-cf-id: yZXWoDUdEUbaVQym6hkaYgVOM0QCA27407IIieZyTCIdpaqjfr0TuQ==

So, I’m tending to feel that it is WPT bug.

Interesting, glad you can see that your headers are working as expected. If it bugs you enough, you can file issues with WPT here: https://github.com/WPO-Foundation/webpagetest/issues