bryancall commented on issue #8989: URL: https://github.com/apache/trafficserver/issues/8989#issuecomment-4014223489
**Investigation Summary — `cache` option behavior in the compress plugin** The documentation for the `cache` option was misleading. Here's what the code actually does and what testing on ATS 11.0.0 (master, ASAN build) confirms. **What `cache` actually controls** (from `compress.cc` lines 792-801): The `cache` option only affects what happens when the compress transform is active (i.e., when the client sends `Accept-Encoding`): - **`cache true`** (default): Caches the **compressed** (transformed) response. Disables caching of the uncompressed version from that same request. - **`cache false`**: Caches the **uncompressed** (untransformed) response. Does not cache the compressed version. Compression happens on-the-fly from the cached uncompressed content on subsequent requests. **What the docs said (incorrectly):** > When set to `true`, causes TS to cache both the compressed and uncompressed versions of the content as alternates. This is wrong. `cache true` does NOT cache both versions from a single request. It only caches the compressed version. **Why it seems to work anyway:** The compress plugin adds `Vary: Accept-Encoding` to all compressible responses. This causes ATS to treat requests with and without `Accept-Encoding` as separate cache entries (alternates). So after both a gzip client and a non-gzip client have each made a request, both variants end up in cache — but this is due to ATS's normal `Vary`-based alternate handling, not the `cache` option itself. **Test results on ATS 11.0.0 (ASAN build):** | Test | cache=true | cache=false | |------|-----------|------------| | 1st request (gzip) | TCP_MISS (compressed cached) | TCP_MISS (uncompressed cached) | | 2nd request (no gzip) | TCP_MISS (goes to origin) | TCP_MISS (goes to origin) | | 3rd request (gzip) | TCP_MEM_HIT | TCP_MEM_HIT (re-compressed on-the-fly) | | 4th request (no gzip) | TCP_MEM_HIT | TCP_MEM_HIT | Both settings produce the same end result after one request of each type. The difference is a performance tradeoff: - `cache true`: Avoids re-compression CPU on subsequent gzip cache hits - `cache false`: Avoids storing a second (compressed) cache object, compresses on-the-fly The reporter's workaround (`cache false` + `remove-accept-encoding true`) is valid and works correctly. **Resolution:** Documentation corrected in #12946 to accurately describe the `cache` option behavior. No ASAN errors observed during testing. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
