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/multipart: encode non-US-ASCII characters in Content-Disposition #33801

Open
odeke-em opened this issue Aug 23, 2019 · 4 comments

Comments

@odeke-em
Copy link
Member

commented Aug 23, 2019

I am coming here from CL https://go-review.googlesource.com/c/go/+/190217 where @pascaldekloe has submitted a change that makes *mime/multipart.Writer generate a "Content-Disposition" value after invoking mime.FormatMediaType instead of using a quote escaper.

In a comment https://go-review.googlesource.com/c/go/+/190217/1#message-b06f1016c7862f1d35ef7a12dc95fc4426a48178
@mattn asks

I don't have strong opinion. Just for the note. This make forcibly the filename encode
with rfc 6266. So older browser will not work after this change. Do we need to leave
a way to output raw-filenames?

This issue is to have a discussion, but I'll also loop in some security folks @mikesamuel @empijei, to help evaluate or just beware of the update.

@odeke-em odeke-em added this to the Go1.14 milestone Aug 23, 2019

@pascaldekloe

This comment has been minimized.

Copy link
Contributor

commented Aug 24, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented Aug 26, 2019

CC @bradfitz @minux (although both of those owners seem to be away from GitHub at the moment)

@bcmills

This comment has been minimized.

Copy link
Member

commented Aug 26, 2019

@pascaldekloe, what is the rationale for / impact of the proposed change?

Is this a feature request to support non-ASCII value for those names, or a bugfix for names that RFC requires the library is required to support?

Either way, why is there no corresponding documentation change in the CL? (Presumably the change widens the set of acceptable names, so the doc comment should probably mention which names are acceptable either way.)

@pascaldekloe

This comment has been minimized.

Copy link
Contributor

commented Aug 26, 2019

Not sure what to say here. I was surprised by the sloppy escape and fixed it. No more HTTP violation with UTF-8 or control characters in the header.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.