Vary options doesn't seem to work

[cyu]

Vary options doesn't seem to work

[cyu]

What version are you using? What's does your config block look like?

[chrisnicola]

Just updated to 0.3.1:

    config.middleware.insert_before ActionDispatch::Static, "Rack::Cors", :debug => true, :logger => (-> { Rails.logger }) do
      allow do
        origins '*'
        resource '/assets/*',
          methods: [:get, :options],
          headers: :any,
          vary: ['Accept-Encoding'],
          credentials: true
      end
    end

[chrisnicola]

I've also tried vary: 'Accept-Encoding'

[cyu]

It's returning Vary: Origin and not Vary: Options, right?

The vary: option is only available on the master branch - I haven't released it yet.

[chrisnicola]

Sorry Origin yes.

[chrisnicola]

Ah I'll switch to that and retry. My mistake.

[chrisnicola]

@cyu so related to why I was doing this. There seems to be a very unusual bug with IE where if Vary: Origin is set at all, it breaks font loading (amazingly even if it isn't a cross origin request since IE sends the Origin header for all font requests no matter what).

[jjb]

@chrisnicola

Thanks for sharing this, there is surprisingly little coherent info on this widespread problem out there.

Could you share your final config, and maybe some explanation?

Why did you add Accept-Encoding to Vary? Why not just remove Origin?

[chrisnicola]

@jjb I actually am struggling to recall now, though I've noted that I need that for IE11 for some reason.

I believe the problem was that Rack-Cors was automatically setting Vary: Origin by default. The verision on master branch lets you override this. I think I set Accept-Encoding as that tends to be a pretty standard Vary option to have enabled, though I'm not sure it's required for the fix.

You have to realize that I was only able to debug this because my staging environment was behind Cloudflare, which was loading fonts fine and it seemed to be because Cloudflare was optimizing some of the headers on cached resources. Production uses Amazon Cloudfront which is a bit less dynamic. So I was trying to get the headers I was producing to match exactly what Cloudflare was using it order to find the culprit. After a fair amount of testing it turned out that the Vary: Origin header was the culprit. (For reasons that I'm sure will be forever be shrouded in IE historical mystery.)

I'd typically report a bug to the IE team, but quite honestly nothing seems like more of a waste of time than reporting IE bugs. I just finished working around another random IE11 flexbox layout bug today.

Edit: Sorry forgot my final config (btw are you having this problem?)

      allow do
        origins '*'
        resource '/assets/*',
          methods: [:get, :options],
          headers: :any,
          vary: ['Accept-Encoding'], # Required or IE11 fonts will break
          credentials: true
      end

It's worth noting I'm not sure all of this is required. Once I got it to match Cloudflare's output I was happy. I do think credentials: true was also important either for this or something else. Either way this seems to be a pretty safe config and the Cloudflare team seems to know what they are doing.

[jjb]

@chrisnicola thanks for the followup! ah yes the joys of IE even in 2015.

I put rack-cors in place so I could track JS errors with rollbar. It then intercepted my font requests and started causing problems. I use https://github.com/ericallam/font_assets/ -- I described my problem more here: ericallam/font_assets#39 (which I ultimately realized has nothing to do with font_assets).

In the end I could never replicate the behavior in a development environment, even when using different IP addresses for app and assets. So I gave up on the whole thing and just took our rack-cors and gave up on rollbar JS reporting for the time being.

[mupkoo]

I think that vary option is not working. I tried it using the master branch and a brand new Rails 4.2.6 project.

# config/application.rb
config.middleware.insert_before 0, 'Rack::Cors' do
  allow do
    origins '*'
    resource '*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options],
      vary: ['Accept-Encoding', 'Origin']
  end
end

curl 'http://localhost:3001/' -X OPTIONS -H 'Access-Control-Request-Method: GET' -H 'Origin: http://dummy-origin.com' -v

and this is the response that I get

*   Trying ::1...
* Connected to localhost (::1) port 3001 (#0)
> OPTIONS / HTTP/1.1
> Host: localhost:3001
> User-Agent: curl/7.43.0
> Accept: */*
> Access-Control-Request-Method: GET
> Origin: http://dummy-origin.com
>
< HTTP/1.1 200 OK
< Content-Type: text/plain
< Access-Control-Allow-Origin: http://dummy-origin.com
< Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
< Access-Control-Expose-Headers:
< Access-Control-Max-Age: 1728000
< Access-Control-Allow-Credentials: true
< Server: WEBrick/1.3.1 (Ruby/2.3.0/2015-12-25)
< Date: Wed, 27 Jul 2016 16:01:03 GMT
< Content-Length: 0
< Connection: Keep-Alive
<
* Connection #0 to host localhost left intact

Should I open a new issue or am I doing something wrong?

[cyu]

The :vary option currently applies to the actual resource request. Your example is of the preflight OPTIONS request.

Do you really need to return a Vary header for preflight requests? What problem are you trying to fix?