I didn’t notice this post earlier, and I’m a little surprised noone else responded yet.
First off, I would like to ask what exactly you mean by “add support for”? Because if you mean “have Fastly do the compression”, I don’t think that’s very feasible. SDCH is the most effective if you have a lot of content shared between multiple objects, and thus requires analysis of not only multiple pieces of content, but also analysis of traffic patterns to figure out which content goes together a lot. That’s currently beyond our scope, and is better done in coordination with other FEO (Front End Optimization).
However, even if you have SDCH all handled at the Origin, we currently normalize the
Accept-Encoding header for the most common case (gzip). We’re in the process of adding a header that shows the original value of
Accept-Encoding, so customers will be able to do normalization that takes other forms of compression into account.
I personally doubt SDCH will get much traction, since it really is a PITA to get the most efficient use out of it. However,
brotli is the new kid on the block, and shows great promise! (With compression and decompression speeds equal to or greater than
gzip, and better compression ratios.) So that’s why we’re adding the support for customers to do their own