Activity

1. melvincarvalho

   added

   bugSomething isn't workingSomething isn't working

   on May 12, 2026
2. melvincarvalho commented on Jun 10, 2026

   

   melvincarvalho

   on Jun 10, 2026

   ContributorAuthor

   More actions

   Findings (2026-06-10): verified fixed — closing

   Live-verified against current gh-pages (jss --conneg --public, JSON-LD resource at /public/test.jsonld):

   GET with…	Returns
   Accept: application/ld+json, text/turtle, application/json (this issue's case)	application/ld+json ✅
   Accept: text/turtle, application/ld+json	text/turtle ✅
   Accept: application/ld+json;q=0.5, text/turtle	text/turtle ✅ (q-weights honored)

   The fix landed via #325 (April 2026): parseAcceptHeader in src/rdf/conneg.js now parses q-values and sorts descending (stable sort preserves listed order for equal q), and selectContentType returns the first supported type. The behaviour reported here — Turtle returned regardless of Accept order — can't reproduce on GET.

   Two adjacent gaps surfaced during verification (tracked separately)

   1. HEAD ignores Accept — curl -I (which this issue's repro used!) returns the stored content type no matter what Accept says, diverging from GET on the same resource. RFC 9110 HEAD/GET parity violation. Filed as conneg: HEAD ignores the Accept header — content-type diverges from GET on the same resource #552.
   2. Extensionless resources serve application/octet-stream ignoring Accept — already tracked as Content type is coupled to document extension #460 (content type coupled to document extension).

   Neither affects this issue's specific claim, which is about GET priority ordering and is fixed. Closing.
3. melvincarvalho

   closed this as completedon Jun 10, 2026
4. melvincarvalho

   added

   stale-fixedOpen issue whose described problem no longer reproduces on current main; verify and closeOpen issue whose described problem no longer reproduces on current main; verify and close

   on Jun 10, 2026