-
Notifications
You must be signed in to change notification settings - Fork 18k
mime: FormatMediaType fails to detect non-ASCII bytes #28849
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
Milestone
Comments
This issue seems like it is really two separate issues:
(1) is a bug-fix. (2) is a feature request; please file it separately. |
fix for 1 seems easy, either change range to use []byte() or change check to compare >= 0x80.
I guess you're right about 2 being kind of separate issue, I will probably fill feature request for that.
I've already changed my code to accomodate FormatMediaType failing and retrying with parameter encoded with mime.BEncoding, which works okay with email clients I tested with.
…On 2018 11 19 16:05:08 UTC, "Bryan C. Mills" ***@***.***> wrote:
This issue seems like it is really two separate issues:
1. The current validation checks runes instead of bytes.
2. Ideally you'd like RFC 2231 encoding.
(1) is a bug-fix. (2) is a feature request; please file it separately.
|
Change https://golang.org/cl/150417 mentions this issue: |
Change https://golang.org/cl/150498 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Nov 20, 2018
CL 150417 was submitted before I could recommend this change to remove an unnecessary allocation. Updates #28849 Change-Id: I4cd655f62bb3d00eda6c997f074785385bceee0c Reviewed-on: https://go-review.googlesource.com/c/150498 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
bradfitz
pushed a commit
that referenced
this issue
Nov 21, 2018
FormatMediaType used rune&0x80==0 to check if parameter values consisted of valid ascii charaters. Comparing strings using their runes instead of their bytes leads to some non-ascii strings to pass as valid. E.g. the rune for 'Ą' is 0x104, 0x104 & 0x80 => 0. Its byte representation is 0xc4 0x84, both of which result in non zero values when masked with 0x80 Fixes #28849 Change-Id: Ib9fb4968bcbbec0197d81136f380d40a2a56c14b Reviewed-on: https://go-review.googlesource.com/c/150417 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
bradfitz
added a commit
that referenced
this issue
Nov 21, 2018
CL 150417 was submitted before I could recommend this change to remove an unnecessary allocation. Updates #28849 Change-Id: I4cd655f62bb3d00eda6c997f074785385bceee0c Reviewed-on: https://go-review.googlesource.com/c/150498 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yeah.
What operating system and processor architecture are you using (
go env
)?irrelevant.
What did you do?
https://play.golang.org/p/mkEHhue4cKm
Tried
FormatMediaType
with different unicode characters in parameter values.What did you expect to see?
One of:
FormatMediaType
encoding parameters with any unicode characters as per RFC 2231 section 4.FormatMediaType
consistently accepting all unicode characters. That's probably not really compliant with current standards, but works with few email clients I tried. I like RFC 6532, but it doesn't have any mention ofContent-Type
orContent-Disposition
though, so this option can probably be ignored.FormatMediaType
consistently rejecting all characters impossible to represent by US-ASCII.What did you see instead?
Only characters covered by ISO-8859-1 are detected as unicode and cause encoding failure.
Characters whose rune values (actual unicode values, not UTF-8 encoded) aren't
& 0x80
pass test and are included in output.Additional info & reporter's opinion
I noticed this looking at source code of
FormatMediaType
and noticing that it containsif character&0x80 != 0
check, however it iterates thru string withrange value
(notrange []byte(value)
which would be correct).I really don't like that it doesn't at least support RFC 2231 encoding, now I will either need to reimplement this function myself, or encode filename parameter using either
mime.BEncoding
ormime.QEncoding
.Adding proper check there and failing to encode could cause some issues if implementations relied on old broken behavior, I guess.
The text was updated successfully, but these errors were encountered: