Conversation
|
Should I just add a new test block to the types tests or add |
Signed-off-by: Frazer Smith <[email protected]>
|
Any thoughts on this @climba03003? I know you've worked a lot on the rewrite of this module so didn't want to go ahead and merge without your input! |
climba03003
left a comment
climba03003
left a comment
There was a problem hiding this comment.
I am thinking the needs of disable option.
Since this library is just provides whatever information the consumer needs, it is up to the consumer to decide if he / she want what header.
It is a bit overkill provide an option to disable feature. (The function here is just a giant map lookup. Should not be costly.)
So... is that a tentative approval? 😆 |
|
Yes, but I do believe |
This PR adds the ability to disable the
Content-Typeresponse header via thecontentTypeoption.Whilst the automatic setting of the
Content-Typeresponse header is great, it's not always right for some edge cases, such as for vendor-specific or proprietary extensions.Likewise, the charset is hardcoded to
utf-8fortext/plain,text/htmlandapplication/jsonfiles; these types can support more than just utf-8 character encoded content so it'd be nice to get around that.Related to fastify/fastify-static#480.
Checklist
npm run testandnpm run benchmarkand the Code of conduct