Avoid duplicate compression work

Choose one layer to compress a given response. POM Cache supplies the canonical body; either the origin server or the CDN should own its transfer encoding.

“Both compression features are enabled” is not automatically wrong, but their interaction must be intentional and observable.

Model A: CloudFront owns compression

This is the standard POM pattern:

POM Cache index.html
→ origin sends identity body
→ CloudFront selects Brotli/Gzip
→ viewer decodes it

The origin does not send Content-Encoding. CloudFront uses the viewer’s normalized Accept-Encoding, eligibility checks, and cache policy.

Advantages:

• no compression CPU in PHP or Apache;
• one canonical origin file;
• edge variants are created near viewers;
• POM Cache purging remains format-independent.

Model B: the origin owns compression

An origin server can apply Brotli or Gzip:

POM Cache index.html
→ Apache compresses response
→ origin sends correct Content-Encoding
→ CloudFront passes and caches it

CloudFront does not recompress a response that already has Content-Encoding. The origin must negotiate correctly, send the matching header, and keep Accept-Encoding variants isolated.

This model can be useful without CloudFront or for types the CDN does not compress.

Find the current owner

Request the origin directly through the approved diagnostic path with:

Accept-Encoding: br,gzip

If the origin response already has Content-Encoding, origin compression is active. Possible owners include:

• Apache Brotli/Deflate output filters;
• another reverse proxy;
• PHP zlib.output_compression;
• an optimization plugin;
• a managed hosting feature.

Then request through the CDN and compare. Do not infer ownership only from the public response.

Failure patterns

CPU work with no added benefit

The origin compresses every miss while the architecture intended CloudFront to do it.

Incorrect Content-Encoding

The header says Brotli/Gzip but the body is identity, or the body is encoded twice. Browsers can report decoding failures or truncated content.

Cache-key mismatch

An encoded response is reused for a client that did not advertise support.

Old identity object

CloudFront was configured for compression after the object was cached and continues serving the earlier uncompressed copy.

Competing header rules

Several layers overwrite or duplicate Content-Encoding or Vary.

Move to one owner

To standardize on CloudFront:

1. confirm edge compression and its cache policy are ready;
2. disable origin compression for the selected behavior;
3. verify the origin returns identity with the correct Content-Length;
4. invalidate controlled edge paths;
5. test Brotli, Gzip, and identity viewers.

To standardize on the origin:

1. configure server negotiation and Vary: Accept-Encoding;
2. verify encoded bytes and headers before the CDN;
3. ensure the CDN caches the encoding variants correctly;
4. understand that CloudFront will pass through the origin encoding;
5. invalidate old variants.

POM Cache remains unchanged

Neither model requires .br or .gz files in the POM Cache tree. Do not add a PHP compression step to phase two merely because public delivery should be compressed.

Use Verify Brotli or Gzip delivery after every ownership change.