Skip to content
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

mime: Loosen the ParseMediaType error checking #13448

Closed
cention-sany opened this issue Dec 2, 2015 · 8 comments
Closed

mime: Loosen the ParseMediaType error checking #13448

cention-sany opened this issue Dec 2, 2015 · 8 comments

Comments

@cention-sany
Copy link

What version of Go are you using (go version)? 1.5.1
What operating system and processor architecture are you using? Ubuntu Intel 64 bits
What did you do? use mime.ParseMediaType
What did you expect to see? error mime: invalid media parameter
What did you see instead? no error or different type of error

The following is actually output from bad email client for an attachment mime header:

Content-Type: application/octet-stream; name=Viktoria C
Content-Disposition: attachment; filename=Viktoria C

This type of header email will output "mime: invalid media parameter" error under golang. But the same email when open/parse by Thunderbird and other C email library will give the attachment with file name Viktoria instead of Viktoria C.

I understand the main problem is the bad email client and not golang library but the same mail can be opened with other application which is not using Golang library may give the wrong perspective that Golang library capability - the fact is Golang error handling too good that expose those scapegoat buggy software problem. But just because of this tiny error the whole email can not be parsed.

May be Golang library can have something as this to discriminate certain error that can be recovered.

@ianlancetaylor
Copy link
Contributor

I'm sorry, I don't understand this bug report. Can you be more precise about what you want changed? Can you show a demonstration program?

@cention-sany
Copy link
Author

using mime.ParseMediaType to parse the line Content-Type: application/octet-stream; name=Viktoria C or Content-Disposition: attachment; filename=Viktoria C will give error mime: invalid media parameter. I hope Golang library can parse these successfully such as other application which output the file name Viktoria.

@ianlancetaylor
Copy link
Contributor

For this kind of thing it really helps to show a code example. Does this show the problem you are reporting? http://play.golang.org/p/uZH0-U2Qgh .

@ianlancetaylor
Copy link
Contributor

If that is the problem, I think RFC 2045 is pretty clear: the value must be a token or a quoted string. A token may not contain a space. This works: http://play.golang.org/p/fb0OkjnU2L .

@cention-sany
Copy link
Author

Ya. I understood the problem lie on the Content-Type: application/octet-stream; name=Viktoria C. Probably Golang library can treat the line as Content-Type: application/octet-stream; name=Viktoria with error instead of return empty and error.

@bradfitz
Copy link
Contributor

bradfitz commented Dec 2, 2015

Is this a bad email client that matters?

Which one?

Where is the bug report for their side?

I'd rather not violate RFCs unless there's a very good reason.

@cention-sany
Copy link
Author

The bad email client that I mentioned most probably is using different non-Golang library for composing the email. I don't have any knowledge on the mail client but just our application received a raw email with this type of bad formatted Content-Type.

Ya, before I posted I did doubt about whether Golang team will even consider this. I just try it. You may not violent the RFC by still returning the error, just different type of error. But currently mime library return "", nil, error check this which wipe out any of the previously successfully parsed mediatype and params.

It would be easier if other email client give error for the same type of email but Thunderbird and some other mail client can read the email. But our email client application can not because we use Golang library to parse the email.

Anyway feel free to close it. There is always others workaround. Thank for the time.

@ianlancetaylor
Copy link
Contributor

I am closing because I don't see what we can usefully do. Trying to sort out the meaning of a value that does not follow the RFC is not a job for the standard package. That has to be done using some sort of application logic.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants