Repository navigation
fix: accept parameterized OTLP content types - #82
Conversation
VibeSWE
left a comment
There was a problem hiding this comment.
Independent Sol6.1 review of 5d837c7a67d5c8f454654dc6ee67b43c888fcb29 against 547c5118583b8e3884a2b6920c3b5a0ffa675f87: no actionable findings.
The shared OTLP classifier implements the approved essence-only policy, including ignoring malformed parameters, case normalization, and HTTP SP/HTAB trimming. JSON dispatch, original unsupported-header diagnostics, missing/non-text header handling, and protobuf rejection remain consistent with the brief. No additional media-type aliases or plain JSON/Kinesis changes were introduced.
Reviewed the five added tests and the parent-provided validation artifacts matching source SHA-256 b264192148b860074f0ec77c481e865c93588d350854fa0d327c6d18ac40a769: 1,050 passing library tests, both 40-case HTTP runs, and the independent 41-case classifier matrix. No builds or tests were rerun for this review.
Description
OTLP logs, metrics, and traces reject valid JSON requests such as
Content-Type: application/json; charset=utf-8because dispatch compares the complete header string. Classify the parsed type/subtype using Actix's existing mime re-export so parameters, media-type case, and surrounding HTTP whitespace no longer prevent ingestion.Dispatch deliberately ignores parameter text, including malformed parameters, and preserves HTTP 400 responses and existing diagnostics for missing/unsupported headers. Protobuf remains unsupported; parameterized protobuf gets the existing protobuf-specific error. OTLP JSON suffix aliases and gRPC remain out of scope. No dependencies or public interfaces change.
Validation
cargo clippy --locked --all-targetspassed with existing warnings outside the changed file; formatting and whitespace checks passed.Backend checks used
P_BUILD_NO_UI=1,CARGO_BUILD_JOBS=4, and serialized Cargo commands.Need help on this PR? Tag
@codesmith-botwith what you need.