That makes sense, should we define the cache headers list and what we consider far-future expire?

I think the headers would be Cache-Control with max-age and/or an Expires. As for the time that should be considered future, I recall generally 1 year as being normal for this. But 1 week would probably work just as well. In any case, the threshold should be filterable.

Also, there could be some cases where an author needs for an asset to not have a far-future expiration date. In that case, there could be a filter to exclude it from the test.

Lastly, in addition to far-future expiration, the test could also check for ETag and Last-Modified and if no far-future expiration is present, do a secondary request to the same asset URL with If-None-Match and If-Modified-Since, respectively. If those return with 304 Not Modified then that could pass the test as well, although not as good as far-future expiration.

@westonruter out of curiosity, do you think this is something that a site admin could take direct action on?

Good question. Maybe not directly. They'd have to ask their host to fix the static asset response headers. But I do know that some plugins can modify .htaccess files to add the required rules, assuming they're on Apache.