24

I am using an S3 bucket behind Cloudfront with CORS enabled. If the client makes a request with the Origin header, then S3 (and cloudfront) respond with a "Vary: Origin" header, however if the request is made without the Origin, header then the response does not contain any Vary Header.

This is problematic because I use a resource from cloudfront/s3 in an img tag, in which case the browser makes the request without the Origin header, and then later make an ajax request for said image. The browser then uses the cached version of the image, without the Access-Control-Allow-Origin header, and therefore denies the request.

Is there any way to get S3 to always return the "Vary: Origin" header?

Thayne
  • 6,619
  • 2
  • 42
  • 67

3 Answers3

34

I made an account just to answer your question, because there are very few good answers around for this kind of problem (and a few related ones).

The problem you describe happens for some reason primarily in chrome, FF and IE seems to be smart enough not to share cache between AJAX and regular calls in these instances.

The Problem

Lets first describe why the problem happens for future readers:

  • Browser (Chrome) ask the server using a regular <img> or <script> tag. If the server is in the same domain it does not includes an CORS headers.
  • Server (S3) returns the resource. If no Origin header was present in the request it does not attach CORS headers in the reply as they are redundant.
  • Browser (Chrome) try and get the resource again using AJAX, but this time doesn't really go to the server but looks at the cached resource.
  • Browser (Chrome) The cached version does not have CORS headers. It will drop the request as Access-Control-Allow-Origin violation or other related problems.

The solution

In HTML5 there is an attribute called crossorigin that can be added to tags to signify that they need to send origin information. Possible values are crossorigin='anonymous' and crossorigin='use-credentials' these are quite irrelevant to the question asked but as it says in the documentation:

By default (that is, when the attribute is not specified), CORS is not used at all.

https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_settings_attributes

So just create your image tags like this <img src='cloundfront.path' crossorigin='use-credentials'>

Thats it. Its quite obscure so I hope that this answer saves some research time to a bunch of people.

drdrek
  • 459
  • 1
  • 4
  • 6
  • 2
    Would I be right in assuming that `crossorigin="use-credentials"` would be equivalent to calling `withCredentials` on an XHR request? If so, would `crossorigin="anonymous"` work just as well, as far as making sure CORS headers are returned? I'd rather not allow my static images to do things like set cookies if I can help it. – Jeremy T Sep 06 '16 at 20:03
  • 1
    This caching issue was killing me in our Chrome Extension. There was so much to consider especially in Chrome Extension with CORS. This answer was clear and helped us to pinpoint the issue. Thank you . Also just for a reference, if you want to avoid image attribute `crossorigin`, you can do a `fetch` request with `cache:no-store` which will bypass cache. – theHarsh Jul 23 '20 at 10:33
  • I agree with @JeremyT I think `crossorigin="anonymous"` is the more prefferred approach for static assets. This is what fixed the issue for me when fetching cached images with cors enabled. – JoeMoe1984 Mar 12 '21 at 17:03
15

Another solution would be configuring your CloudFront distribution to automatically turn Non-CORS requests into CORS requests. This is possible by adding a CORS header to each request CloudFront sends to S3 using the recently added CloudFront feature "Control Edge-To-Origin Request Headers".

See the feature announcement here: https://aws.amazon.com/blogs/aws/cloudfront-update-https-tls-v1-1v1-2-to-the-origin-addmodify-headers/

And the documentation here: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/forward-custom-headers.html.

Kristian Hanekamp
  • 2,429
  • 1
  • 21
  • 13
  • 2
    Nice, that will force Access-Control-Allow-Origin but for Vary: Origin? – caub Jun 19 '17 at 17:36
  • 1
    If you force Access-Control-Allow-Origin on every request, the "Vary: Origin" is no longer needed, since the header no longer varies between requests. It is no longer problematic if the browser uses a cached version, since that version is also CORS-enabled. – Kristian Hanekamp Jun 20 '17 at 20:40
  • 7
    However, if you force CloudFront to always send "Origin: X.domain.com" to S3, then there is no way for CloudFront to return "Access-Control-Allow-Origin: Y.domain.com". In other words, this force header solution only works if you are returning a "Access-Control-Allow-Origin: *" wildcard response header or only ever are returning a _single_ domain in our "Access-Control-Allow-Origin" header. – timmfin Jul 21 '17 at 20:39
  • We force CloudFront to send Origin to S3: phhh. CORS configured on s3. S3 thinks that origin is different then host and then answers with ACA* headers. So instead of vary - every request gets cors headers – Ivan Borshchov Feb 11 '21 at 15:51
1

I stumbled on an easy way to make Cloudfront always add a "Vary: Origin" header, albeit undocumented as far as I can tell: You can force the "Vary" header by including "Origin" in the CloudFront cache key.

On the Cloudfront distribution click "Edit behaviour", find the heading "Cache key and origin requests". If you are using "Legacy cache setting" click select "Origin" under "Add header". If you use the newer Cache policy then you need to click "Create policy" and add the Origin under "Cache key settings", then go back and use the policy you just created.

My use case is HMTL5 video subtitle tracks that don't send an Origin if you use crossorigin="anonymous", and if there is no Origin, there is no Vary: Origin.

Jan M
  • 2,205
  • 21
  • 14
  • Hi, it looks like the etag does not change. So even with the header vary:origin chrome still use the cache. Do you have a solution for this ? – Hugo Mallet Mar 31 '22 at 10:22
  • For static S3 files the etag typically doesn't change. And if the etag hasn't changed then it should be fine to use the cached version, that's what an etag is for. – Jan M Apr 01 '22 at 11:08
  • The problem is that if the file was cached without cors headers a first time, then the second download with crossorigin="anonymous" will use the same cache and fail – Hugo Mallet Apr 05 '22 at 13:18
  • Yes, but see the solution by Kristian Hanekamp above, this now no longer an issue with the new feature update – Jan M Apr 06 '22 at 14:07