* refactor: Update to use fasthttp.VisitHeaderParams
The implementation of forEachParameter was upstreamed to fasthttp, so
use that version instead of maintaining our own.
* refactor: use map for header params
The previous implementation of content negotiation used some difficult
to understand techniques in order to reduce allocations, potentially
hurting maintainability. The more natural approach for storing and
comparing unordered media-type parameters is to utilize maps. While the
resulting code still isn't as simple as it could be, it's a step closer.
To reduce allocations, we use a sync.Pool. This actually reduces in fewer
allocations than before at 3 or more parameters. The net result is nearly
identical performance for zero parameters, almost-as-good performance for
1-2 parameters, and better performance for 3+ parameters.
---------
Co-authored-by: Jason McNeil <sixcolors@mac.com>
* ✨ feat: add support for parameters in content negotiation
Attempts to approach the level of support offered by express,
but behavior may differ in unusual corner cases.
Some key behaviors from Express that are implemented:
- If an offer does not have every parameter listed in the given Accept,
it is rejected.
- Parameters do not affect specificity.
- In a given specificity, more parameters gives greater precedence
- Parameters are unordered
- Matching is case-insensitive
- Surrounding quotes for parameter values are stripped
- If an Accept type specifies a parameter more than once, the last
value provided is taken.
- Parameters after q are not processed.
https://www.rfc-editor.org/rfc/rfc9110#name-parameters
* doc: properly attribute reader.go for validHeaderFieldByte
* fix: remove underscores from fuzz test name
* test(forEachParameter): improve coverage
* doc: add comment clarifying RFC 9110 non-compliance for corner case
nickajacks1