Description
StreamFormat::from_accept_header's doc comment (crates/pjs-core/src/infrastructure/http/streaming.rs, around line 125-129) states:
Wildcard matching is restricted to exactly */* and application/* (case-insensitive), which vote for [Self::Json] at their own q.
This is no longer accurate after #520 (headers-accept crate migration). It describes the pre-#520 hand-rolled parser's behavior, where a */*/application/* entry had a hardcoded vote for StreamFormat::Json. Since #520, negotiate() locks each of the 4 SUPPORTED_MEDIA_TYPES candidates onto its own best-specificity matching Accept entry before checking q — so a wildcard entry can result in any of the 4 formats (SSE, NdJson, Binary, not just Json), depending on which concrete candidates are separately excluded via their own q=0.
This exact behavior change is correctly and explicitly documented in CHANGELOG.md's #520 entry, and pinned by a dedicated regression test, but the function's own rustdoc still states the old, narrower claim — misleading a reader of cargo doc (this is a pub fn on a published crate, pjson-rs).
Reproduction Steps
- Read the doc comment on
StreamFormat::from_accept_header (lines ~106-142 of crates/pjs-core/src/infrastructure/http/streaming.rs), specifically the wildcard bullet.
- Compare against
crates/pjs-core/tests/http_streaming_comprehensive.rs::test_stream_format_from_accept_header_q_zero_concrete_type_falls_through_to_wildcard, which asserts Accept: application/json;q=0, */* resolves to StreamFormat::ServerSentEvents, not StreamFormat::Json.
- Live-confirmed against the real router over a real TCP connection (not just the unit test):
curl -H "Accept: application/json;q=0, */*;q=0.5" .../frames/stream returns content-type: text/event-stream, contradicting the doc comment's "vote for Self::Json" claim.
Expected Behavior
The doc comment's wildcard bullet should describe the actual current outcome: */*/application/* match all 4 supported candidates, defaulting to StreamFormat::Json only when no other candidate's own more-specific Accept entry with a distinct q wins or is separately excluded — matching the nuance already captured in CHANGELOG.md's #520 entry.
Actual Behavior
The doc comment claims the wildcard always votes for Self::Json, which is false whenever a different concrete candidate (e.g. application/json) is separately excluded via its own q=0 entry in the same header.
Environment
- Version: pjson-rs 0.6.3, commit
9ccb5dd (introduced) through current HEAD
- Features:
http-server
- Platform: macOS (darwin), also applies to any platform — this is a documentation-only issue
Logs / Evidence
Live curl reproduction against a real serve_with_limits-backed router (CI cycle 033):
$ curl -s -D - -o /dev/null -H "Accept: application/json;q=0, */*;q=0.5" http://127.0.0.1:3199/pjs/sessions/.../streams/.../frames/stream
content-type: text/event-stream
Description
StreamFormat::from_accept_header's doc comment (crates/pjs-core/src/infrastructure/http/streaming.rs, around line 125-129) states:This is no longer accurate after #520 (headers-accept crate migration). It describes the pre-#520 hand-rolled parser's behavior, where a
*/*/application/*entry had a hardcoded vote forStreamFormat::Json. Since #520,negotiate()locks each of the 4SUPPORTED_MEDIA_TYPEScandidates onto its own best-specificity matchingAcceptentry before checkingq— so a wildcard entry can result in any of the 4 formats (SSE, NdJson, Binary, not just Json), depending on which concrete candidates are separately excluded via their ownq=0.This exact behavior change is correctly and explicitly documented in
CHANGELOG.md's#520entry, and pinned by a dedicated regression test, but the function's own rustdoc still states the old, narrower claim — misleading a reader ofcargo doc(this is apub fnon a published crate,pjson-rs).Reproduction Steps
StreamFormat::from_accept_header(lines ~106-142 ofcrates/pjs-core/src/infrastructure/http/streaming.rs), specifically the wildcard bullet.crates/pjs-core/tests/http_streaming_comprehensive.rs::test_stream_format_from_accept_header_q_zero_concrete_type_falls_through_to_wildcard, which assertsAccept: application/json;q=0, */*resolves toStreamFormat::ServerSentEvents, notStreamFormat::Json.curl -H "Accept: application/json;q=0, */*;q=0.5" .../frames/streamreturnscontent-type: text/event-stream, contradicting the doc comment's "vote forSelf::Json" claim.Expected Behavior
The doc comment's wildcard bullet should describe the actual current outcome:
*/*/application/*match all 4 supported candidates, defaulting toStreamFormat::Jsononly when no other candidate's own more-specificAcceptentry with a distinctqwins or is separately excluded — matching the nuance already captured inCHANGELOG.md's#520entry.Actual Behavior
The doc comment claims the wildcard always votes for
Self::Json, which is false whenever a different concrete candidate (e.g.application/json) is separately excluded via its ownq=0entry in the same header.Environment
9ccb5dd(introduced) through currentHEADhttp-serverLogs / Evidence
Live curl reproduction against a real
serve_with_limits-backed router (CI cycle 033):