feat: remove tspecials from type/subtype #317
Conversation
| @@ -1,7 +1,7 @@ | |||
| Content-Type: multipart/alternative; boundary="----=_Part_10541_215446765.98298273965074084" | |||
|
|
|||
| ------=_Part_10541_215446765.98298273965074084 | |||
| Content-Type: <html> | |||
| Content-Type: | |||
There was a problem hiding this comment.
This had to be adjusted as <html> was no longer failing validation due to < and > being removed in fixMangledMediaType
|
Part of the goal of enmime is to flag bad input, I know that we were already silently trying to fix up borderline media type strings; but this character stripping is quite aggressive in my opinion. I'm OK making enmime more resilient to malformed messages, but they should either be optional or add an Error to the Part. Adding Errors feels like the more useful solution here, but I'm not sure what effort level is required to implement it. |
My reasoning behind the change was that any special character in the content type/subtype will fail the default mime parser while stripping out any garbage can result in a valid content type, but I perfectly understand you don't want to make this the default behavior.
I have made the invalid character stripping opt-in via the parser option. Let me know if this is acceptable. Happy to address any other issues you see with the PR. |
|
Apologies for the long loop, should be adjusted per your comments. |
|
Thank you! |
According to the RFC, content type and subtype cannot contain special characters and any such character will fail parsing. Removing the characters from the type/subtype can help successfully parsing the content type that contains some extra garbage.