Match application/json when Accept includes charset - #112
Conversation
kilisamemarisaaa
left a comment
There was a problem hiding this comment.
I found two actionable issues at exact head e855534:
-
The
fixes #62claim is not satisfied. Issue #62's reproducer isAccept: application/ld+json;profile=http://www.w3.org/ns/json-ld#expandedwithmediaType(['application/ld+json']); running this head still returnsundefinedbecause onlycharsetis filtered andprofileremains a required parameter. Please either removefixes #62or include the profile behavior and a regression test before claiming the issue is fixed. -
Filtering
charsetfor every media type changes parameter matching in a way that can select an unacceptable representation. At this head,Accept: text/plain;charset=utf-8with provided['text/plain;charset=iso-8859-1']returns the ISO-8859-1 type. Media-range parameter semantics are media-type-specific; an unconditional filter cannot safely assume that everycharsetparameter is irrelevant. The existing discussion in #35 and the maintainer guidance in #41 also treat charset/other parameters as type-specific. Please retain parameter matching by default (or document and scope an explicit policy) and add a regression test for conflicting charset values.
Ignoring charset on every Accept range made a utf-8 offer select an iso-8859-1 type. Keep the application/json;charset=utf-8 case, but require the values to agree when both sides set charset.
|
Both notes from the review are in c71457a.
|
Accept: application/json;charset=utf-8listedapplication/jsonfrommediaTypes(), butmediaTypes(['application/json'])returned nothing because every Accept parameter had to exist on the provided type.charseton Accept is not a type discriminator unless the provided type also names one.application/json;charset=utf-8still matchesapplication/json. Conflicting charsets (utf-8vsiso-8859-1) do not match.text/html;level=1vstext/htmlis unchanged.profileonapplication/ld+jsonis a different parameter and is not in this change.