Accept `q` weights are ignored during response media type negotiation

[MicroMilo]

Summary

createHandler parses Accept header parameters but does not appear to apply the q weight when selecting the response media type. As a result, application/json;q=0 can still be selected, and a lower-priority supported media type can win only because it appears earlier in the header.

Steps to reproduce

Use a handler/media-type negotiation test with supported response types application/graphql-response+json and application/json, then send requests with:

Accept: application/json;q=0

and:

Accept: application/json;q=0, application/graphql-response+json;q=1

A source-equivalent repro produced:

application/json;q=0 => application/json
application/graphql-response+json;q=0 => application/graphql-response+json
application/xml, application/json;q=0 => application/json
application/json;q=0, application/graphql-response+json;q=1 => application/json
application/graphql-response+json;q=0.1, application/json;q=1 => application/graphql-response+json

Expected behavior

• q=0 should make that media type unacceptable.
• Accept: application/json;q=0 should not select application/json; if no other supported media type is acceptable, the handler should take the existing 406 Not Acceptable path.
• Accept: application/json;q=0, application/graphql-response+json;q=1 should select application/graphql-response+json.

Actual behavior

The first syntactically matching supported media type wins, even when its q value is 0 or lower than another supported media type later in the header.

Evidence

• The source-equivalent repro above shows q=0 values still being selected.
• src/handler.ts splits the Accept header and parameters, has a TODO for handling the weight parameter q, assigns acceptedMediaType, and breaks on the first matching supported type.
• The same file already has a 406 Not Acceptable path when no media type is accepted.

Suggested fix

Parse q from each Accept media range, default missing q to 1, exclude candidates with q=0, and select the supported media type with the highest effective priority before falling back to 406.

Regression tests could cover q=0 and two supported media types with conflicting priorities.

Additional context / Related coverage

A current GitHub search did not identify exact upstream issue/PR coverage for Accept q weights. Adjacent coverage includes issue #120 for charset handling and PR #23 for behavior when Accept is missing.

---

Submitted with Codex.

[enisdenjo]

very much true, the q weights are not considered when parsing the accept headers. would you be willing to open a PR implementing support? 👀

[MicroMilo]

Thanks for confirming. I opened a focused draft PR implementing Accept q-weight support with regression tests: #153

I kept the change scoped to the handler media-type selection path and noted the local full-suite environment caveats in the PR body.