You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There has been several issues raised over the years regarding sections of the InboundEmail payload being encoded with unknown/unsupported encodings and two improvements have been made to lessen the problem:
Fallback to UTF-8 when an invalid/unsupported encoding is specified
These two improvements have considerably reduced the problem with encoding but I was thinking we could be smarter than blindly fallback to UTF-8 when an invalid/unsupported encoding is specified. I recently found out about the UTF Unknown project which attempts to determine which encoding was used to encode binary data by probing the content. This would enhance our ability to properly decode a given section of a webhook, even if the encoding is unspecified or invalid.
The text was updated successfully, but these errors were encountered:
There has been several issues raised over the years regarding sections of the InboundEmail payload being encoded with unknown/unsupported encodings and two improvements have been made to lessen the problem:
These two improvements have considerably reduced the problem with encoding but I was thinking we could be smarter than blindly fallback to UTF-8 when an invalid/unsupported encoding is specified. I recently found out about the UTF Unknown project which attempts to determine which encoding was used to encode binary data by probing the content. This would enhance our ability to properly decode a given section of a webhook, even if the encoding is unspecified or invalid.
The text was updated successfully, but these errors were encountered: