Images not displaying a Cache TTL

Hello @outdoors

Thank you for your inquiry and I am happy to assist you with this.
Can you please share if the issue started after you enabled the CDN or was the issue there before that?
Can you also please share the entire .htaccess file (you can use https://www.codepile.net/)\
Also can you please check the Behaviours on the AWS consoled and make sure that AWS is respecting the existing headers?
https://aws.amazon.com/blogs/aws/cloudfront-update-configurable-max-and-default-ttl/
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html

Thanks!

Hello,

Not aware if the issue started after I enabled CDN; All was initially configured and then began testing with GT Metrix.

URL for .htaccess file https://www.codepile.net/pile/q37MW1mY

Viewing Amazon Distribution Default behavior
(This Distribution is created in Amazon Lightsail; SSL and referenced in Route 53 DNS with A record “Alias to Cloudfront Distribution as per AWS engineers. https to https.
Cache Behavior
Cache wp-includes/*
Cache wp-content/*

Advanced cache settings:
Updates every day
Allow GET, HEAD, and OPTIONS methods
forward HTTP headers I specify
forward no cookies
forward all query strings
Last reset cache 11/18/2020 8:12AM

Let me know if I missed anything
Thanks

Hello,
Thank you for the information.
The .htacces files look fine all necessary rules are added e.g:

ExpiresByType image/jpeg A31536000
ExpiresByType image/png A31536000

Can you please share your website URL?
can you also please temporarily disable the CDN and see if the issue persists?
Thanks!

Hello,

Web URL https://mapnhike.com

If I understood correctly:
Disabled CDN settings (W3 Total Cache – General Settings – CDN – unchecked Enable)
All set (Let me know and will purges cache from W3 and reset cache from Lightsail Distribution.

Viewing Lightsail Distribution and really no way to disable other than delete Distribution and recreate(let me know otherwise). Really don’t want to do that unless it is a must ?? …Let me know if this is the only way to verify the images not propagating the cache control.

CSS, JavaScript files working; cache-control max-age xxxxxxx

Hello,
After disabling CDN.. (W3)

Purged all cache through W3 and Reset Cache from Lightsail Distribution
May take a few moments

Thanks

Hello,

Just wanted to make sure I reference the documentation for Amazon Lightsail Distribution.
https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-changing-default-cache-behavior

It caches everything in
wp-inlcudes/*
wp-content/*

Referenced from Lightsail Article Above:

Advanced cache settings
The advanced settings can be used to specify the cache lifespan of content on your distribution, the allowed HTTP methods, HTTP header forwarding, cookie forwarding, and query string forwarding. The advanced settings that you specify apply only to the directory and files that your distribution caches, including the directory and file overrides that you specify as Cache.

You can configure the following advanced settings:

Cache lifespan (TTL)

Controls the amount of time your content stays in your distribution’s cache before your distribution forwards another request to your origin to determine if your content has been updated. The default value is one day. Reducing the duration allows you to better serve dynamic content. Increasing the duration means that your users get better performance because your files are more likely to be served directly from the edge location. Increasing the duration also reduces the load on your origin, because your distribution pulls content less frequently.

Note
The cache lifespan value that you specify applies only when your origin does not add HTTP headers such as Cache-Control max-age, Cache-Control s-maxage, or Expires to your content.

So no way to post/upload images into discussion; Allows me to “Choose the headers that are forwarded to your origin by your distribution. The response from your origin is cached by your distribution only for the specified headers” Right now it is configured “Forward headers I specify to include “host”

Hello, I made sure to speak with an AWS Engineer as well to rule out the Amazon Lightsail Distribution Configuration (CloudFront TTL Settings):

This is the Engineers Comments:

Thank you for your reply and feedback.

I have checked the screen shots that you have kindly provided and can see that both URLs match wp-content/* caching behavior. However, I can see that there is a cache control header set by the origin with both of them with value max-age=10 and this will override CF TTL values:

~ % curl -v /dev/null /wp-content/uploads/2020/09/logo_header-300×260.png” target=”_blank” rel=”nofollow noopener noreferrer”>https://d1j7gyeyn3ijac.cloudfront.net/wp-content/uploads/2020/09/logo_header-300×260.png

* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< content-type: image/png
< content-length: 6851
< server: Apache
< x-frame-options: SAMEORIGIN
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< last-modified: Tue, 17 Nov 2020 15:14:30 GMT
< accept-ranges: bytes
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
< referrer-policy: no-referrer-when-downgrade
< pragma: public
< via: 1.1 95f372def48b268a5ae55a9a5ecb4479.cloudfront.net? (CloudFront), 1.1 f0300a9921a99446a44423d996042050.cloudfront.net? (CloudFront)
< x-amz-cf-pop: DUB2-C1
< date: Wed, 18 Nov 2020 18:20:11 GMT
< etag: “1ac3-5b44ef38c7682″
< cache-control: public, s-maxage=10
< x-cache: Miss from cloudfront
< x-amz-cf-pop: DUB2-C1

====================
The same for /wp-content/plugins/elementor/assets/lib/eicons/fonts/eicons.woff2?5.9.1″ target=”_blank” rel=”nofollow noopener noreferrer”>https://d1j7gyeyn3ijac.cloudfront.net/wp-content/plugins/elementor/assets/lib/eicons/fonts/eicons.woff2?5.9.1

cache-control
public, s-maxage=10
content-encoding
gzip
content-type
application/font-woff2
date
Wed, 18 Nov 2020 18:30:35 GMT
etag
“149a0-5b4296743ae56-gzip”
pragma
public
referrer-policy
no-referrer-when-downgrade
server
Apache
================================================

In case the origin sends Cache-Control header with the object, the value specified in the header will be applied as long as it falls between the minimum and the maximum TTL values configured in the CF’s caching behavior. If it’s greater than the maximum TTL, then the maximum TTL will be applied. If it’s lower than the minimum TTL, then the minimum TTL will be applied. Whatever the default TTL value is in this scenario, it will be ignored.

In case the origin doesn’t send Cache-Control header with the object, then the default TTL value should be applied as long as falls between the minimum and the maximum TTL values. If the default TTL value is greater than the maximum TTL, then the maximum TTL will be applied. If it’s lower than the minimum TTL, then the minimum TTL will be applied. So, the default TTL value is the main player here.

That being said, CF TTL values is out of the game here as there is a cache control header set by the origin.

On the other hand, CloudFront serves a file from an edge location until the cache duration that you specified passes—that is, until the file expires. After it expires, the next time the edge location gets a user request for the file, CloudFront forwards the request to the origin server to verify that the cache contains the latest version of the file. The response from the origin depends on whether the file has changed:

If the CloudFront cache already has the latest version, the origin returns a 304 status code (Not Modified).
If the CloudFront cache does not have the latest version, the origin returns a 200 status code (OK) and the latest version of the file.

Conclusion:

If a viewer request hits a specific caching behavior in CF, the default TTL value for that request will be applied UNLESS there is a cache control header set by the origin. If the origin sends a cache-control header, this will override CF TTL values.

I remain at your disposal for any further clarification.

Wish you a great day ahead!

References:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio-explained.html

We value your feedback. Please share your experience by rating this correspondence using the AWS Support Center link at the end of this correspondence. Each correspondence can also be rated by selecting the stars in top right corner of each correspondence within the AWS Support Center.

Best regards,
Tariq A.
Amazon Web Services

Hello @outdoors

Thank you for the information. I’ve checked the website and the image:
https://mapnhike.com/wp-content/uploads/2020/09/logo_header-300×260.png

accept-ranges: bytes
age: 47675
cache-control: public
content-length: 6851
content-type: image/png
date: Thu, 19 Nov 2020 06:45:26 GMT
etag: "1ac3-5b44ef38c7682"
last-modified: Tue, 17 Nov 2020 15:14:30 GMT
pragma: public
referrer-policy: no-referrer-when-downgrade
server: Apache
status: 304
strict-transport-security: max-age=31536000; includeSubDomains; preload
vary: Accept-Encoding
via: 1.1 fd2756277dcf50743fb09f4526b54aca.cloudfront.net (CloudFront)
x-amz-cf-id: 3cOPwYHIi8shnsSV1VX7K-W1qg1nRf3iOCUy7f6BS8kSHaWMPwXl5g==
x-amz-cf-pop: VIE50-C1
x-cache: Hit from cloudfront
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block

As you can see Cache-control is set to Public.
strict-transport-security: max-age=31536000; means that you have enabled HTTP Strict Transport Security policy in Performance>Browser cache and since The time is set, in seconds (as defined under the “Expires Header Lifetime” box of “Media & Other Files”), it means that the settings are correct when it comes to W3 Total Cache.
Now it appears that something else is setting the cache-conrol header for images in your case.
In your .htaccess I can see that Header append Cache-Control “public” which is correct.
If you are using some image optimization plugin there is a possibility that in the options of that plugin there is a cache-control option for images.
Also, make sure to check your httpd.conf for any rules that may override .htaccess.

You may want to check the .htaccess file in parent directories. They are recursive to a limit.
The configuration directives found in a .htaccess file are applied to the directory in which the .htaccess file is found, and to all subdirectories thereof. However, it is important to also remember that there may have been .htaccess files in directories higher up. Directives are applied in the order that they are found. Therefore, a .htaccess file in a particular directory may override directives found in .htaccess files found higher up in the directory tree. And those, in turn, may have overridden directives found yet higher up, or in the main server configuration file itself.

Thanks!

Hello Marko

Thank you for all the variations of why this may be happening. Will go through each one and report back any findings. Good to know that the settings are correct in W3 Total Cache.

I am using ShortPixel and will verify any settings that may be affecting the header, the httpd.conf, and any search for any .htaccess files in parent directories. Will report back for those that may have similar issues.

Thanks again for assistance!

Hello @outdoors

You are most welcome.
Please let me know your findings.
Also, make sure that the option in Perfomrance>page Cache>Advanced>”Compatibility mode:” is disabled as it may cause similar things sometimes.
Thanks!

Checked with ShortPixel
Verified there are no settings for a cache-control policy
They do not add anything to the .htaccess file as well
Response From ShortPixel Team: “Unfortunately, we are not related to this – ShortPixel only replaces the physical images and in your case it does not add anything to the htaccess”

Checked other .htaccess files: All located in sub-directories and not located in any parent directories

Found nothing in the httpd.conf that might be construed as referencing rewrite to the images
Could post for your review if needed

Checked Page-Cache-Advanced-Compatibility mode” – This is unchecked

Will continue to search for the reason this is happening and sure it will become apparent soon

Hello @outdoors

Thank you for the information.
As for the s-maxage:
s-maxage=<seconds> Overrides max-age or the Expires header, but only for shared caches (e.g., proxies). Ignored by private caches.
If a response includes an s-maxage directive, then for a shared cache (but not for a private cache), the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header. The s-maxage directive also implies the semantics of the proxy-revalidate directive (see section 14.9.4), i.e., that the shared cache must not use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. The s- max-age directive is always ignored by a private cache.
I hope this helps!

Hello Marko,

Not sure how to apply the last response to address my particular situation; because I am not as familiar with this specialty. I have some understanding but not how to address what you have outlined in order to populate a (cache-control: public, max-age=) for those 13 files. Which is consistent across all pages in regards to cache-control policy.

Is there someone who would give me a quote to identify this issue? Maybe purchase the PRO plugin and get this resolved?

Using GTMetrix there are 13 files out of the 28 request that have No CACHE TTL. This is the consistent throughout all pages.

Here are 3 examples (files) that have a Cache TTL
GTMetrix returns files that have a CACHE TTL (cache-control: public, max-age=)

analytics.js
Request URL: https://www.google-analytics.com/analytics.js
age: 2048
cache-control: public, max-age=7200
strict-transport-security: max-age=3136000; IncludeSubDomains; preload
x-cache: Hit from cloudfront
referer: https://mapnhike.com/

4ceac.js
Request URL: https://d1j7gyeyn3ijac.cloudfront.net/wp-content/cache/minify/4ceac.js
age: 431904
cache-control: max-age=31463637
strict-transport-security: max-age=3136000; IncludeSubDomains; preload
x-cache: Hit from cloudfront
referer: https://mapnhike.com/

JTURjIg1_i6t8kCHKm45_cJD3gnD_vx3rCs.woff2
Request URL: https://fonts.gstatic.com/s/montserrat/v15/JTURjIg1_i6t8kCHKm45_cJD3gnD_vx3rCs.woff2
age: 319178
cache-control: public, max-age=31536000
strict-transport-security: max-age=3136000; IncludeSubDomains; preload

Of the 13 files that do not have a cache-control with a max age; 6 are png files, 3 are .woff files, 1 is jpg, 2 are javascript, and 1 is css.

Is there someone who can identify why those 13 files are not populating a “(cache-control: public, max-age=)” policy and instruct me how to implement.

Thank you

Hello @outdoors

I was stating that those files have s-maxage=10 that Overrides max-age or the Expires header.
To answer your question, no, upgrading to Pro will not resolve this as this is not related to any of the pro features. As I mentioned, either it’s on the server, Some misconfiguration on the CDN (since the issue persists when you disable CDN it’s unlikely) or some other plugin /proxy is setting s-maxage=10
Thanks!

• This reply was modified 3 years, 12 months ago by Marko Vasiljevic.

Hello Marko,

OK ; Thank you for narrowing down the issue to mis-configuration on the CDN or some other plugin. If I am unable to identify the cause, will seek out the technical expertise needed to identify the culprit.

Again thank you for your input