This repository has been archived by the owner on Jul 2, 2021. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.