Closed HenryGau closed 9 years ago
i'm pretty sure that's an invalid content type
even so,
'*/*'
should still match it, right?
Currently we specifically don't match any invalid content type, which is why your match fails.
Think about it: body-parser needs to parse the charset from the type. If the type is malformed (like your example), then anything it would get would be meaningless. The answer is that you either need to send a valid content type, or add a middleware prior to body-parser to clean up the content-type header so it's valid.
In fact, the body-parser module accepts a function as the type option which allows you to implement whatever logic you like, avoiding this library. Please see the body-parser readme for more information / open an issue for help over at body-parser, please.
Thanks, I will use that function from body-parser then. The only confusion is when using wildcard, '/', I thought it will match any content type having '/' character without validity check.
I added some more text in Readme here to clarify the logic you already have: https://github.com/jshttp/type-is/pull/13
Gotcha. It does match any content type. Would you have expected it to match foo/bar/baz as well? If not, then you are already agreeing that it should do validation.
Basically since the header is a string, it could be anything. HTTP defines the exact syntax of a content type, so we validate that the string is one so we can compare apples to apples.
Hi,
The background: Alipay system is sending a POST request with header of: content-type: application/x-www-form-urlencoded; text/html; charset=utf-8
after using bodyparser with type-is internally, there is a big issue: current behavior
expected behavior
@didayche