Page MenuHomePhabricator

experiment with reenabling compression between applayer's TLS terminators and edge caches
Open, MediumPublic

Description

This has been tried before with very unfortunate side effects (see, for instance, the tale of woe that is T125938), but, this time we would try it without involving Mediawiki, PHP, or even Apache.

Envoy itself has a Compressor filter. This is worth experimenting with; hopefully responses compressed by it are more compatible with ats-be and varnish-fe, and it would also allow us to sidestep previously-buggy Mediawiki output generation code, etc.

We wouldn't want to send the same Accept-Encoding header upstream to Apache/Mediawiki. Envoy's Compressor configuration accepts a remove_accept_encoding_header Boolean, so that's easy enough.

Open questions here involve figuring out the appropriate testing to do and the best mechanism for a canary deployment.

(Later on, in the far future, there's potentially-tricky possible work in balancing between gzip and Brotli compression, but for now, gzip is the only thing supported by either Envoy or ATS.)

Event Timeline

ArielGlenn triaged this task as Medium priority.Sep 28 2020, 9:55 AM
Ladsgroup renamed this task from experiment with reënabling compression between applayer's TLS terminators and edge caches to experiment with reenabling compression between applayer's TLS terminators and edge caches.Nov 21 2020, 9:11 PM
BBlack added a subscriber: BBlack.

The swap of Traffic for Traffic-Icebox in this ticket's set of tags was based on a bulk action for all tickets that aren't are neither part of our current planned work nor clearly a recent, higher-priority emergent issue. This is simply one step in a larger task cleanup effort. Further triage of these tickets (and especially, organizing future potential project ideas from them into a new medium) will occur afterwards! For more detail, have a look at the extended explanation on the main page of Traffic-Icebox . Thank you!