Compress plugin should send always Vary: accept-encoding if content-type matches

[mlibbey]

When a request comes to a remap that has the compress plugin, but does not have an Accept-encoding: header that indicates the plugin should compress, but, the object would otherwise be compressible we should still add a Vary: accept-encoding.

Say an ATS close to the origin in a cache hierarchy (a parent) receives a request that does not ask for compression on a compressible object. It responds, and, because the response does not have Vary: accept-encoding, an ATS closer to the client (child) think that it is the only possible variant. For the next request that does ask for compression, that 1st ATS in the path will have a cache hit for the uncompressed object and send it uncompressed.

If however the parent originally sends Vary: accept-encoding, the child can still ask the parent for the compressed version.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. Marking it stale to flag it for further consideration by the community.

[bneradt]

@mlibbey Can you please clarify whether this is still an issue? Looking at the plugin code, it looks like it tries to handle Vary intelligently. If possible, can you add an AuTest for this? If you don't have time, can you describe an example request and response which causes this issue.

[bneradt]

Assigning to @vmamidi .

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. Marking it stale to flag it for further consideration by the community.

[bryancall]

This is now implemented. The compress plugin adds Vary: Accept-Encoding for all compressible content regardless of whether the current request asked for compression, so a downstream cache in a hierarchy can still request the compressed variant. The change was made in #12741 and first shipped in release 10.1.1. Closing as resolved.