Missing Vary Header

[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 (https://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'

[guyisra]

+1

[zephyr-dev]

+1

[sealabcore]

+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 ❤️

[schneems]

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]

I have no checked but I can see how this happens. Let say that we requested
/tasks/1 using Ajax, and the previous page has the same url. When we click
the back button the browser tries to get the response from its cache and it
gets the javascript response. With vary we "fix" this behavior because we
are telling the browser that the url is the same but it is not from the
same type what will skip the cache.

Although this fix the behavior I don't think it is a sane default for Rails
always send vary for accept header because this can cause unneeded cache
invalidations. But I can be wrong and with a deeper investigation we can
conclude that this default makes sense.

On Tue, Mar 31, 2015, 11:59 Richard Schneeman notifications@github.com
wrote:

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?

—
Reply to this email directly or view it on GitHub
#318 (comment).

[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]

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.