Apache HTTPD / Representation, proxying, and capacity / Lesson 11

Compression filters and response-header scope

Review representation changes, negotiation, Vary, and header tables as one response contract.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish compression eligibility from actual client negotiation.
Explain why response headers need context and duplicate-value review.

A response can be transformed after handling

Output filters can transform a response generated by a file or application handler. Compression changes the representation bytes and can trade transfer size for CPU work. Parcel’s text documentation and JSON may benefit under appropriate traffic and client conditions, while already compressed media or sensitive reflected responses have different considerations. A filter is not a universal performance improvement. Identify content type, response size, client capabilities, caching behavior, and actual CPU and network evidence before choosing policy. This course compresses no live content and generates no traffic.

Read prerequisites and response scope

The fragment below selects DEFLATE by media type through the supported filter directive and adds a synthetic response label through mod_headers. It assumes the relevant filter, deflate, headers, and content-type behavior and is never loaded. No response is generated. The custom header is teaching metadata, not a security control or a complete cache policy. A content-type mismatch can affect filter selection, and inherited or backend headers can interact with the final response. Review the actual supported contexts and ordering rather than treating the snippet as an installation recipe.

apache A non-runnable response-filter fragment

AddOutputFilterByType DEFLATE text/html text/plain application/json
Header set X-Parcel-Representation "lab"

Required modules and actual content are absent assumptions. No compression ratio, browser behavior, cache correctness, header value, or server result is measured.

Representation variants need a cache contract

Compression depends on supported negotiation such as Accept-Encoding and the selected module behavior. The documented deflate integration handles relevant Vary information, but additional variation and other intermediaries still need review. A cached compressed response must not be served to a client that did not accept that coding. Do not manually set a fixed Content-Length after body transformation. Validators and cache keys must describe the actual representation contract. More filters or manually duplicated Vary fields can complicate rather than clarify behavior.

Header tables and conditions affect final values

mod_headers supports different timing and response-table behavior, including onsuccess and always forms. The same header name from a backend, another module, or another table can produce duplicates or surprising results. Review set, add, append, merge, and unset according to intent rather than repeatedly setting values until one browser looks correct. Error and redirect responses may follow different paths. A diagnostic label does not establish correct authorization, privacy, or cache behavior, and security-related headers need application-specific policy rather than a universal copied list.

Evaluate a declared eligibility rule only

The complete local model below chooses a synthetic gzip label when a type is eligible and the declared client capability set includes gzip. It does not parse a real Accept-Encoding header, q values, wildcard negotiation, Apache filter order, or actual compression. It illustrates that content eligibility and client capability are independent conditions. Real validation needs actual response bytes and headers through every relevant cache and proxy path in a separately authorized process. Retain negative cases so an optimization does not weaken representation correctness.

python A synthetic compression-eligibility model

eligible_types = {"text/html", "application/json"}
def representation(content_type, accepted):
    return "gzip" if content_type in eligible_types and "gzip" in accepted else "identity"
print(representation("application/json", {"gzip"}))
print(representation("application/json", set()))
print(representation("image/png", {"gzip"}))

Expected output

gzip
identity
identity

Only strings and sets are evaluated. No body is compressed, HTTP header parsed, server invoked, or performance measured.

Common errors and fixes

Compression is enabled for every response as a universal speed improvement.

Why it happens: CPU cost, content properties, clients, and sensitive reflection behavior were ignored.
How to fix it: Choose and verify a bounded representation policy for the actual application.
Prevent it next time: Measure transfer and processing together with correctness.

A compressed variant is cached without the required negotiation distinction.

Why it happens: Representation variation was omitted from the cache contract.
How to fix it: Review Vary and cache key behavior across all intermediaries.
Prevent it next time: Test clients with different accepted codings.

The same header is set in multiple tables and appears twice.

Why it happens: Effective response scope and backend contributions were not reviewed.
How to fix it: Trace header sources and choose the intended operation and table.
Prevent it next time: Include errors and redirects in header verification.

Check your understanding

1. Does an eligible JSON type guarantee that every client receives gzip?

Show worked solution

No. Negotiation and module policy also matter. The local model requires declared capability and is intentionally not a full header parser. Actual clients, caches, and response paths need appropriate authorized validation.

2. Why not force a fixed Content-Length after adding compression?