Safari is caching the CORS redirect images (Instructure Canvas image upload to AWS S3 bucket) even though, the response header includes "Cache-Control: no-cache, no-store". This causes Safari to send an Options call to validate the cached image. This causing chaos with the redirect headers and fails the image load. Chrome & Firefox are not caching the image. They do not send the Options method, so they do not have problems getting the image a second time.
According to Mozilla, "To disable caching of a resource, you can send the following response header"
- GOOD: "Cache-Control: no-store"
- BAD: "Cache-Control: no-cache,no-store" (they are contradictory)
no-cache:
The response may be stored by any cache, even if the response is normally non-cacheable.
However, the stored response MUST always go through validation with the origin server first
before using it, therefore, you cannot use no-cache in-conjunction with immutable. If you mean
to not store the response in any cache, use no-store instead. This directive is not effective in
preventing caches from storing your response.
Is it possible that Safari is taking the "no-cache" directive and storing the image, and not bothering to read the second "no-store" directive? If so, why do so many posts recommend to use both directives to the "Cache-Control" header instead of just the "no-store"?
These posts have loads of upticks, and include the double directive, I'm wonder if they are working for people who use Safari: How do we control web page caching, across all browsers?, macOS Safari caching response, while headers specify no caching
Here's the Instructure Canvas code that adds both directives. I'm tempted to make a pull to remove the "no-cache" caching directive.
