Compression and HTTP headers

HTTP headers are how the edge and origin negotiate almost everything that is not the body: encoding, access, caching, and range behaviour. Compression and headers are tightly coupled — a compression choice changes what byte ranges mean, and a header misconfiguration can silently fragment the cache or break playback. This page covers the decisions that matter most.

gzip and brotli

Compression shrinks text-like responses — HTML, CSS, JS, JSON, manifests — often by 70–90%, cutting egress and improving time-to-first-byte.

Enable compression for text content types and leave already-compressed media alone — re-compressing MP4, WebP, or AV1 wastes CPU for no gain. Let the edge negotiate via Accept-Encoding and cache variants keyed on encoding.

Compression versus byte ranges

This is the interaction that breaks video delivery if ignored.

• Byte ranges in an HTTP response refer to the encoded representation, not the original bytes. If the edge compresses an object, Range: bytes=0-1023 means the first kilobyte of the compressed stream, not the source.
• Clients that compute ranges from an uncompressed Content-Length will slice the wrong bytes and get corrupt output.
• The safe rule: never compress range-served media. Serve video, audio, and images uncompressed over range requests, and reserve compression for whole-object text assets.
• If a text asset must be both compressed and range-served, use strong validators consistently so partial compressed objects can be cached safely, and normalise overlapping or non-ascending ranges at the edge.

See Why tube-site video buffers for how range and compression mismatches degrade seeking.

CORS

Cross-origin requests are common on adult platforms: a player on one hostname pulling manifests and segments from a media hostname, or an embed on a partner site. Configure CORS deliberately.

• Return Access-Control-Allow-Origin only for origins you trust; avoid a blanket * on protected media.
• Include the headers your player actually needs (Range, Content-Type) in Access-Control-Allow-Headers, and expose Content-Range, Content-Length, and Accept-Ranges so range logic works cross-origin.
• Remember that a CORS preflight is a separate request; keep preflight responses short-lived and cacheable, and do not let them hit the origin on every playback.
• CORS headers are part of the response and are cached downstream, including at the shield.

Custom headers

Custom request and response headers carry metadata, security policy, and origin context.

• Response headers can add security policy, CORS, and cache directives at the edge. Because they are cached with the object, changing one requires invalidation to take effect.
• Request headers can identify the resource or environment to origin, but must never carry secrets in cleartext or per-viewer tokens into origin logs.
• Header additions and removals count against a per-resource budget; consolidate overlapping rules.

Header normalization

Inconsistent headers quietly cost money.

• Case and whitespace — normalise header names and values so equivalent requests share a cache entry.
• Vary discipline — Vary: Accept-Encoding is expected; Vary: User-Agent fragments the cache into thousands of variants and should be avoided.
• Duplicate headers — decide which value wins when origin sends the same header twice; ambiguity breaks downstream consumers.
• Forwarding — strip hop-by-hop headers and any header you do not want reflected to clients or logged at origin.
• Consistency across tiers — because the shield’s headers are cached downstream, normalise at the shield and every edge inherits the corrected form.

Where AdultInfra fits

AdultInfra configures compression, range handling, CORS, and header policy so text stays small, video seeks cleanly, and the cache is not fragmented by header noise. Bring one hostname and the playback or egress problem you want to fix and talk to us.