Just curious, why are you keeping deflate support? I don’t think there’s any browsers that do deflate that don’t do gzip, these days. And other clients that only do deflate are so rare, giving them the uncompressed version is really not a problem.
Guided by the philosophy that “origin knows best”. Put differently, if we want to disable deflate support, it should be up to the origin, not the edge.
In our case, AFAIK, a cache miss on Accept-Encoding isn’t a huge deal (n! == 6), but it’s easy to see how this can be adapted if it is.
It would be interesting in practice to have a metric on how many permutations are actually cached, and what their hit/miss ratio is. I wonder if there’s a way to check?
been wondering the exact same question for a while now. would appreciate if you would come back with updates if you have found an answer as i see you wrote that 15 days ago. thanks!
Regarding Fastly-Orig-Accept-Encoding: I believe it’s not currently working as intended.
If you have the origin shield service activated, Fastly-Orig-Accept-Encoding will be rewritten at the shield, losing the original value from the client.
Say your original Accept-Encoding header from the browser is “gzip,deflate,br” and your custom VCL sets it to “br.” Once the request reaches the origin shield, Fastly-Orig-Accept-Encoding will be set to “br,” not to the original value of “gzip,deflate,br.”
It seems to me that Fastly-Orig-Accept-Encoding should reflect the original Accept-Encoding value as sent by the browser/client. Writing it a second time at the shield can cause issues with testing and troubleshooting.
When it hits origin shield with
Accept-Encoding set to
br, the result will still be
Accept-Encoding: br going to origin, which is the desired outcome, so I don’t see any problem.
Well, in my vcl_recv, I typically run most functionality only once, then mark the request as processed using an X- header, to prevent it from being re-processed at the origin shield. There’s no need to scan through a bunch of conditionals all over again at the shield and duplicate the work. But apparently Fastly is normalizing/sanitizing the Accept-Encoding header both at the receiving server and then again at the origin. And further, the Fastly-Orig-Accept-Encoding header is losing the original value that represented what the browser/client had sent over. There may be cases where some customers would like to access their client’s actual, original Accept-Encoding headers for analytics or other reasons. Regardless, it does seem to make sense to me to only normalize the header once.