fix: match vendor media type case-insensitively#18
Merged
Conversation
The request media type is lowercased on the way in, but the configured vendor was compared as-is, so a mixed-case vendor (e.g. application/vnd.Some.Name+json) never matched and requests silently fell through to Ignore / the v1.0 default. Media types are case-insensitive (RFC 9110 8.3.1, RFC 6838 4.2), so lowercase the vendor in the comparison. The response content-type still echoes the configured casing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
lesnik512
added a commit
that referenced
this pull request
Jul 4, 2026
…#22) * docs(planning): add 1.4.7 release notes Case-insensitive vendor matching fix (#18) plus internal refactors (#17, #21) since 1.4.6. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(planning): record vendor-media-type process-global decision Review #2 candidate B: keep VENDOR_MEDIA_TYPE as class-global state; instance-scoping collides with the response-class mechanism and one-vendor-per-process is accepted. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(architecture): seed capability pages and glossary Living-truth pages for Accept-header version negotiation and OpenAPI schema versioning, plus the ubiquitous-language glossary. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
parse_accept_versioncompared the request media type (already lowercased byget_accept_header_from_scope) againstvendor_media_typeexactly as configured. A mixed-case configured vendor — e.g.application/vnd.Some.Name+json— never matched, so requests silently fell through toIgnoreand defaulted to v1.0.Media types are case-insensitive: RFC 9110 §8.3.1 (type/subtype/parameter-name tokens case-insensitive) and RFC 6838 §4.2 ("Both top-level type and subtype names are case-insensitive").
Fix
Lowercase the vendor in the comparison only:
Robustness principle: liberal in what we accept (case-insensitive match), conservative in what we send — the response
content-typestill echoes the exact casing the user configured (that string is untouched). Normalizing atinitinstead was rejected because it would also rewrite the emitted content-type casing, a change beyond the bug with no spec basis.Tests
TDD:
tests/test_accept.py::test_parse_matches_vendor_case_insensitively— a mixed-case vendor matches a lowercased request media type →ParsedVersion. Failed withIgnore() == ParsedVersion(version=(1, 0))before the fix; passes after.just test-ci— 32 passed, coverage 100%.just lint-ci— ruff + ty clean,planning: OK.Clears the deferred item recorded in PR #17. Planning bundle:
planning/changes/2026-07-04.02-vendor-media-type-case-insensitive/.🤖 Generated with Claude Code