Repository navigation
Conversation
Keep malformed content types rejected by default while allowing an explicitly registered RegExp parser to recover known external values. Keep request handling independent of media type parsing so validation, normalization, and recovery remain encapsulated in the content type parser. Preserve existing catch-all and missing-route behavior. Followup to fastify#6414
climba03003
left a comment
There was a problem hiding this comment.
RFC9110 noted that Content-Type must be singleton field, and may result in combined field value.
I would say we need a proper configuration to allows either first win or last win.
For example, how to deal with multiples different header.
text/plain, application/json
application/json, text/plain, application/json
It allows way too many situation for your fix.
Although Content-Type is defined as a singleton field, it is sometimes incorrectly generated multiple times, resulting in a combined field value that appears to be a list. Recipients often attempt to handle this error by using the last syntactically valid member of the list, leading to potential interoperability and security issues if different implementations have different error handling behaviors.
|
I don't think a setting for that is appropriate. Have a single algorithm that does something vaguely sane by default and let users escape hatch to whatever they want. A setting that's first or last win only isn't a flexible enough escape hatch. Not nessisary imo |
|
Going to rework this, see #6414 (comment) |
Keep malformed content types rejected by default while allowing an explicitly registered RegExp parser to recover known external values. Keep request handling independent of media type parsing so validation, normalization, and recovery remain encapsulated in the content type parser. Preserve existing catch-all and missing-route behavior.
Followup to #6414
Checklist
npm run test && npm run benchmark --if-presentand the Code of conduct