Add Vary header to prevent caching routes with different content types

[carols10cents]

Such as the /me route, which can be requested by the browser for its
frontend HTML or its backend JSON, but the browser should not cache
either and return it for the other one.

Fixes #888.

I was able to reproduce the problem with reloading locally when, instead of using ember serve, I ran npm run build -- --environment production and then served the files in dist using nginx. This change fixed the problem!

@sgrif @jtgeibel do yinz see any reason NOT to set this header for literally any non-asset route?

[jtgeibel]

do yinz see any reason NOT to set this header for literally any non-asset route?

Here is what I see in a clean dist/ after running your npm run build -- --environment production command.

dist
├── assets
│   ├── [...]
├── crossdomain.xml
├── favicon.ico
├── index.html
├── moment
│   ├── fastboot-moment-62eb34042848ca105b39d48fa2474ea3.js
│   └── fastboot-moment-timezone-abadb8be73831ba0ff2208c313da0af0.js
├── opensearch.xml
└── robots.txt

Ideally, the other static files outside of /assets/ would be served with Vary: Accept-Encoding as the response will not vary based on the Accept or Cookie headers. This seems minor to me since we're using end-to-end https in production and thus don't have to optimize for caching proxy servers. We would want to clean this up if we start using CloudFront or CloudFlare. I have some ideas on other changes to our nginx setup and I'll open a separate issue to discuss those.

For all the dynamic responses served by the backend the full Vary: Accept, Accept-Encoding, Cookie header seems appropriate. This will fix the issue we are seeing on production and will prevent us from poisoning any more client caches.

[jtgeibel]

To follow up on this, I think that long term we should look to move the following routes to somewhere under /api:

• GET /me
• GET /me/updates
• GET /me/tokens
• POST /me/tokens
• DELETE /me/tokens/:id
• GET /summary

That would eliminate the need for setting the header in our nginx configuration, which isn't always available (such as during development). I see no issue with merging this PR as a workaround for now. Maybe add something like # TODO: Remove once /me is moved under /api?

The routes listed above are used only by the frontend. The cargo install command does tell the user to visit /me to obtain a token, however even after moving these routes the backend will continue to return index.html and load the appropriate frontend route as it does today.

[carols10cents]

I'm going to merge this in as-is. I do want to move those /me routes in the backend eventually, but I want to fix this issue now :)

bors: r+

[bors-voyager]

Build succeeded

• continuous-integration/travis-ci/push