Why a captured HTTP response can still look compressed in AgentSight

Direct answer: separate capture, HTTP parsing, decompression and SSE interpretation

In the released v1.0.35 collector, add_http_analyzersinstalls an identity-aware SSE pass, then HTTPParser,HTTPDecompressor, a second SSE pass, optional HTTP filters and authorization-header removal. The decompressor only modifies source="http_parser" events whose message_type="response". It neither decrypts TLS nor reconstructs missing transport bytes.

This is a source-level analysis pinned to product commit c1574366122a90c451bca6a84713e28813ab95e2, reviewed 29 October 2026. It synthesizes first-party parser and decompressor tests; it does not claim that a new network experiment was performed for this article.

The codec matrix: exactly what is recognized

The Content-Encoding header is compared case-insensitively. The decoder normalizes its first comma-delimited value to lowercase, accepting gzip, x-gzip, deflate, br, brotli, zstd and zstandard. The source tests exercise gzip, both deflate wrappers, Brotli and Zstandard with constructed compressed bodies. An unrecognized or absent encoding leaves the event untouched.

This is a ten-case implementation reference, not a compatibility benchmark. In particular, taking only the first encoding token is not equivalent to recursively decoding every layer of a stacked Content-Encoding header.

What changes on a successful decode—and what does not

The analyzer obtains compressed bytes from body_hex when it can decode that field; otherwise it falls back to body. If HTTP transfer framing is chunked, it first attempts to remove chunk framing. Successful content decoding writes a new body_hex, a UTF-8-lossy body, has_body,decompressed=true, original_content_encodingand decompressed_body_size. It also sets the event content_length to the decompressed byte length and removes the old content-encoding and content-length HTTP headers.

That transformed content_length is an output-body size, not evidence that the server advertised that number on the wire. The test checks that transport metadata such as transport_handle, capture_fragment_count,capture_original_len and capture_metadata_complete survive decoding. The raw TLS data and the parsed/decoded HTTP response remain different evidence layers.

Why truncated compression is intentionally left untouched

AgentSight's HTTP/1.1 parser has a one-megabyte message-prefix limit, and its documented TLS record capture has a separate limit. When body_truncated=true is set, the response decoder returns immediately; decoding partial compressed bytes could misrepresent both data and length. Other failed decode attempts also preserve the event, without adding decompressed=true.

A useful diagnostic order is: verify a TLS event with correct byte provenance; verify that the HTTP parser emitted a response; inspect body_truncated and body_truncation_reason; read the content-encoding value; then look for decompressed and original_content_encoding. If one of those steps fails, it is too early to conclude the model returned an empty answer. A body prefix may be preserved even when the remainder was not captured.

Why ordering matters for streaming model output

The later SSE processor receives the result of HTTP parsing and decompression. Thus a complete compressed text/event-streamresponse can become parseable SSE text before response-level extraction. For captures with exact transport identity, the earlier SSE pass defers interpretation to the HTTP parser so concurrent connections are not collapsed onto a legacy process/thread key. The presence of an SSE fragment alone does not prove a complete model exchange, reliable accounting, or absence of capture loss.

Pairing and stream identity are separate questions handled by the HTTP exchange correlation reference. The present page answers the narrower question of body decoding fidelity, not which HTTP request a response belongs to.

A reproducible, data-free source check

To audit the released behavior without collecting anyone's model traffic, check out the pinned product source and run its existing decompressor unit tests. The tests construct gzip, zlib/raw-deflate, Brotli, Zstandard and truncated synthetic HTTP events; they also exercise request pass-through and byte-source priority.

git clone https://github.com/eunomia-bpf/agentsight.git
cd agentsight
git checkout c1574366122a90c451bca6a84713e28813ab95e2
cargo test --manifest-path ext/analysis/Cargo.toml http_decompressor::tests

This is a suggested reproducibility procedure, not a command execution performed for this publication. A passing unit test confirms these analyzer cases under its build environment; it does not establish end-to-end probe support for every runtime, kernel, agent or API server. The canonical documentationowns installation and command reference details.

Evidence limits and safe handling

The decoder does not repair missing TLS data, guarantee arbitrary compression nesting, make binary response bodies lossless in text form, or infer agent intent from transport bytes. A missing decoded message may result from attachment, capture, HTTP parsing, compression, SSE parsing, or subsequent materialization; isolate the layer before deciding where failure occurred.

Captures may include model prompts, responses, headers, file paths and remote endpoints. Reproduce with synthetic payloads or scrubbed local evidence; do not upload plaintext captures or secrets to a public issue. For TLS target selection in Docker, see the container discovery study.

Primary references

• HTTPDecompressor implementation and focused unit tests
• Production analyzer ordering
• HTTP parser limits and truncation state
• TLS plaintext byte fidelity and loss contract
• HTTP connection and stream correlation design
• SSE response parsing and identity deferral
• AgentSight v1.0.35 release