Skip to content
This repository has been archived by the owner on Jul 2, 2021. It is now read-only.

brotli compression support #2226

Open
wants to merge 2 commits into
base: dev
Choose a base branch
from
Open

brotli compression support #2226

wants to merge 2 commits into from

Conversation

mszabo-wikia
Copy link
Contributor

In #1929, we removed mobile-wiki's
reliance on an internal DFS bucket to store front-end assets. Unfortunately,
this also removed support for brotli compression (implemented via nginx servers
on the DFS nodes).

This patch restores support for brotli via ember-cli-deploy and
ember-cli-deploy-compress plugins to generate compressed assets during the build
step and serve them via express-static-gzip if the client supports them.

In order to actually enable brotli support, we will need to update our Fastly
VCL as well to ensure that we normalize the Accept-Encoding header to 'br' if
the client supports brotli. If we're not careful, this will invalidate all
mobile-wiki asset URLs, causing clients requesting older versions of asset
URLs embedded in cached HTML to be served a 404 from the current deployment and
fail. To fully remedy this, we may need to re-introduce semi-persistent asset
storage in either s3 or GCS, but for now, let's just change the asset URL paths
so that we can update the VCL logic only for the new paths, without invalidating
the old URLs.

In #1929, we removed mobile-wiki's
reliance on an internal DFS bucket to store front-end assets. Unfortunately,
this also removed support for brotli compression (implemented via nginx servers
on the DFS nodes).

This patch restores support for brotli via ember-cli-deploy and
ember-cli-deploy-compress plugins to generate compressed assets during the build
step and serve them via express-static-gzip if the client supports them.

In order to actually enable brotli support, we will need to update our Fastly
VCL as well to ensure that we normalize the Accept-Encoding header to 'br' if
the client supports brotli. If we're not careful, this will invalidate all
mobile-wiki asset URLs, causing clients requesting older versions of asset
URLs embedded in cached HTML to be served a 404 from the current deployment and
fail. To fully remedy this, we may need to re-introduce semi-persistent asset
storage in either s3 or GCS, but for now, let's just change the asset URL paths
so that we can update the VCL logic only for the new paths, without invalidating
the old URLs.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant