Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Missing Vary Header #318

Open
guilhermesimoes opened this Issue · 12 comments

8 participants

@guilhermesimoes

This bug occurs in Chrome and IE only but apparently it is a problem on Rails' end.

You can reproduce it by simply going to this page (http://secret-journey-4942.herokuapp.com/) and following the 3 steps indicated.

After hitting the back button, the browser will render the javascript returned by XHR to render the page instead of the actual page.

Here's the repository of the site that displays the bug.

This is fixed server-side by sending a Vary header, like so:

response.headers['Vary'] = 'Accept'
@guilhermesimoes guilhermesimoes referenced this issue in rails/jquery-rails
Closed

Missing Vary Header #121

@guyisra

+1

@nowhereman

This bug also occurs in IE 10 and 11.
@guilhermesimoes Can you update your demo with jQuery 1.11.x, please?
Then I could test it with IE 6, 7 and 8!

NB: Chrome 40 has still the bug.

@guilhermesimoes

So, uhh, it's been precisely 2 years since I reported this bug. Is jquery-ujs dead?

@rafaelfranca Has this been addressed in Rails? Do you know if Rails sends a Vary header? I haven't used the newest 4 releases.

@rafaelfranca

No. Rails doesn't send a Vary header. And no jquery-ujs is not dead.

All work of Rails is volunteer and we don't have time to fix all the problems that people may have. If this is a problem for you I recommend to propose a fix, or wait someone want to fix your problem.

@guilhermesimoes

It's just that getting JSON or JavaScript when pressing the back button seems like a glaring bug to me. I'm surprised that in these 2 years more people haven't had this happen to them.

I guess it's just not that common to share the exact same URL for HTML pages and API endpoints.

Anyway, thanks for chiming in @rafaelfranca. I really appreciate all your hard work on Rails :heart:

@guyisra guyisra referenced this issue from a commit in rails/rails
@schneems schneems Enable gzip compression by default
If someone is using ActionDispatch::Static to serve assets and makes it past the `match?` then the file exists on disk and it will be served. This PR adds in logic that checks to see if the file being served is already compressed (via gzip) and on disk, if it is it will be served as long as the client can handle gzip encoding. If not, then a non gzip file will be served.

This additional logic slows down an individual asset request but should speed up the consumer experience as compressed files are served and production applications should be delivered with a CDN. This PR allows a CDN to cache a gzip file by setting the `Vary` header appropriately. In net this should speed up a production application that are using Rails as an origin for a CDN. Non-asset request speed is not affected in this PR.
cfaaacd
@schneems
Collaborator

Can anyone explain why this happens or give some specs or rational behind using "vary"? We've never set that header previously, why is this just now an issue?

@rafaelfranca
@guilhermesimoes

@schneems This has been an issue for a long time. Here's the original chromium issue. There's even people specifically talking about Rails there.

Since I know that I can use a Vary header to correct this behavior, it hasn't bothered me that much. But I thought I'd ping you guys at this 2 year mark, that's all.

@JangoSteve
Collaborator

So, if I'm reading this correctly, it sounds like it's an issue because the browser behavior concerning cached responses for the back (and I presume forward) button changed. Just to clarify, is the only down-side or side-effect that it will cause the browser to not cache AJAX responses when hitting back/forward buttons?

@guilhermesimoes

The only downside is sending an extra header (that is useless in 99% of cases). The browser keeps caching everything as usual (though it may opt not to use the cache). Basically:

  • Without the Vary header, the browser's back button leads to rendering what the server last returned, without taking cache directives into account - which is completely nonsensical in my opinion.

  • With the Vary header, the browser takes into account the Content-Type header before deciding what to render from the cache.

In my opinion, Chrome and IE's behaviors are the ones that should change, not Rails'. We have Content-Type for a reason. But since they won't budge, Rails should either fix it or pressure them...

I honestly don't understand why that Vary header is necessary. Firefox doesn't seem to need it to render pages from its cache correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.