We have an interesting issue with the tool which could be worth investigating. It's very hard to see what's going on because there's no logging output, but it can be seen on this page: https://sturents.com/student-property-research
Scroll down to the heading "Sample research reports" and you should see 4 thumbnails of report front covers. We have found that these tend to always show in Firefox & Edge, sometimes show in Safari and rarely show in Chrome. However it can be sporadic. The images have a 300s TTL at the CF edge, meaning once they show from a given POP they will tend to show for further requests from that POP for a time.
It seems like when they do not show, what's happening is that CF has received a 200 OK response from APIGW, with a content size of 0 bytes. Given the 200 code it seems happy to cache this, and serves the 0 byte image with no content-type header to the end user.
I am uncertain how to simulate this - calling APIGW directly with the same image never seems to return a 0 byte payload. However it does seem like, even if it was hard to simulate this sporadic behaviour, a change to the APIGW implementation to prevent a response with a 0 byte payload would be possible (seeing as there's no chance a 0 byte payload with a 200 status code would be desired by a user)
We are running v12.0.10 (blocked from 12.1 by the AWS provider BC breaks at present)
We have an interesting issue with the tool which could be worth investigating. It's very hard to see what's going on because there's no logging output, but it can be seen on this page: https://sturents.com/student-property-research
Scroll down to the heading "Sample research reports" and you should see 4 thumbnails of report front covers. We have found that these tend to always show in Firefox & Edge, sometimes show in Safari and rarely show in Chrome. However it can be sporadic. The images have a 300s TTL at the CF edge, meaning once they show from a given POP they will tend to show for further requests from that POP for a time.
It seems like when they do not show, what's happening is that CF has received a 200 OK response from APIGW, with a content size of 0 bytes. Given the 200 code it seems happy to cache this, and serves the 0 byte image with no content-type header to the end user.
I am uncertain how to simulate this - calling APIGW directly with the same image never seems to return a 0 byte payload. However it does seem like, even if it was hard to simulate this sporadic behaviour, a change to the APIGW implementation to prevent a response with a 0 byte payload would be possible (seeing as there's no chance a 0 byte payload with a 200 status code would be desired by a user)
We are running v12.0.10 (blocked from 12.1 by the AWS provider BC breaks at present)