Content negotiation appears to ignore Accept header q-values (q=0) during renderer selection

[zainnadeem786]

Summary

While reviewing DRF's content negotiation behavior, I noticed what appears to be an inconsistency with HTTP Accept header quality (q) values.

From my local investigation, media types explicitly marked with q=0 ("not acceptable") can still be selected during renderer negotiation.

Before preparing a patch, I wanted to confirm whether this is intentional behavior or an issue that should be addressed.

Reproduction

Using a local checkout of the current main branch, I tested the following scenarios.

Case 1

Request:

Accept: text/html;q=0, */*;q=1

Observed renderer:

text/html

Expected renderer:

application/json

since text/html is explicitly marked as unacceptable.

Case 2

Request:

Accept: application/json;q=0, text/html;q=1

Observed renderer:

application/json

Expected renderer:

text/html

because application/json has q=0.

Investigation

From local inspection, renderer selection appears to be performed by:

• rest_framework/negotiation.py
  • DefaultContentNegotiation.select_renderer()
  • DefaultContentNegotiation.get_accept_list()

together with media type matching utilities in:

• rest_framework/utils/mediatypes.py

The current implementation appears to match media types based on precedence and specificity but does not appear to consider HTTP quality values when selecting a renderer.

Validation

I added two focused local tests:

• test_client_excludes_zero_quality_media_type
• test_client_prefers_nonzero_quality_media_type

and executed:

python -m pytest tests/test_negotiation.py -q -p no:cacheprovider

Result:

2 failed, 11 passed

The failures consistently reproduce the behavior described above.

Expected Behavior

According to HTTP content negotiation semantics, media ranges with q=0 should be treated as unacceptable, and media types with higher nonzero quality values should be preferred during renderer selection.

Question

Is the current behavior intentional for backwards compatibility, or would a change to honor q values (particularly q=0) be considered acceptable?

If this is considered an issue, I'd be happy to prepare a focused PR with tests and a minimal implementation.

[krotname]

Your two examples match the current DRF behavior, and the docs describe it as intentional.

DefaultContentNegotiation.get_accept_list() only splits the Accept header into tokens. select_renderer() then orders those tokens by media-type specificity with order_by_precedence(), not by quality. In _MediaType, q is explicitly not used as a matching parameter, and application/json;q=0 has the same specificity level as application/json.

The content negotiation docs also say that q values are not taken into account when DRF determines preference.

So with the default negotiator, q=0 does not mean "not acceptable". If you need RFC-style weighting/rejection, the supported route is a custom BaseContentNegotiation subclass. Changing the default behavior would be a documented behavior change, so I would expect that to need maintainer agreement plus tests/docs updates rather than a small bugfix PR.

[browniebroke]

If you need RFC-style weighting/rejection, the supported route is a custom BaseContentNegotiation subclass.

If the first class support is too invasive, we could look into making this path easier.

[browniebroke]

Thanks for flagging this. I didn't know about quality values for that header, but that makes sense, yes.

I've looked at the PRs when content negotiation was touched and didn't find any mention of it, so not sure if it was left out on purpose, but given that it's documented it might be the case.

The cases you gave sound quite niche to me, and it feels like the client would be better off requesting what they want rather than what they don't. I can't find a lot of folks requesting this so that, which confirm my sentiment.

I wonder how complicated adding support would be though, if the change is minimal and targeted, that could be fine maybe? I haven't looked at it in details though...

[zainnadeem786]

Thanks for checking this.

I agree this should not be treated as a small accidental bug if the current behavior is documented. I can try a small prototype to see how invasive proper q handling would be.

My plan would be:

• keep existing behavior unchanged for Accept headers without q values
• ignore media ranges with q=0
• prefer higher non-zero q values before applying the existing specificity ordering
• add focused tests for the two cases above
• update the content negotiation docs to mention the new behavior if the patch remains small

If the implementation turns out to be invasive or risky for backwards compatibility, I’ll report back here rather than opening a large PR.

[zainnadeem786]

@browniebroke I tested a minimal prototype locally.

It keeps the existing behavior for Accept headers without q values, treats q=0 media ranges as unacceptable, and orders nonzero q values before applying the existing specificity rules.

Focused negotiation tests pass locally:

.venv\Scripts\python.exe -m pytest tests/test_negotiation.py -q -p no:cacheprovider
17 passed

[zainnadeem786]

Thanks everyone for the feedback.

I put together a minimal prototype based on the discussion and opened a focused PR for easier review: #9988.