httpheader icon indicating copy to clipboard operation
httpheader copied to clipboard

MatchAccept() doesn't actually implement RFC 7231 Section 5.3.2

Open flamingcow66 opened this issue 2 years ago • 2 comments

The doc for MatchAccept() contains conflicting statements:

// MatchAccept searches accept for the element that most closely matches // mediaType, according to precedence rules of RFC 7231 Section 5.3.2. // Only the bare type/subtype can be matched with this function; // elements with Params are not considered. If nothing matches mediaType, // a zero AcceptElem is returned.

RFC 7231 S 5.3.2 describes q param handling and goes into detail about how to apply it. Not supporting the q param is a valid choice (it's effectively saying "server's priority order takes precedence"), but that's not possible with MatchAccept(), since it skips AcceptElems with parameters entirely.

flamingcow66 avatar Mar 28 '23 00:03 flamingcow66

Hi, thanks for reaching out. Accept contains a list of media-ranges with associated weights (q values). Any given media type can be matched to at most one media-range. The weight isn’t involved in this matching, it applies only when a match has already been located. MatchAccept finds this match for you, but only among media-ranges without media type parameters (AcceptElem.Params). The weight (AcceptElem.Q) and any accept-exts (AcceptElem.Ext) do not affect MatchAccept.

In the example for Accept, if Accept contained text/html;charset=utf-8 instead of just text/html, then MatchAccept(accept, "text/html") would return a zero value.

I will clarify this in the doc, leaving the issue open for now.

vfaronov avatar Mar 28 '23 08:03 vfaronov

Thanks for the clarification! It wasn't clear that Q wasn't included in Params -- this makes it totally usable.

flamingcow66 avatar Mar 28 '23 16:03 flamingcow66