-
Notifications
You must be signed in to change notification settings - Fork 18k
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: FormatMediaType doesn't allow to create Content-Disposition #9624
Comments
Yeah, looks like we're inconsistent here. Content-Dispositions are different, but we've supported them in ParseMediaType forever (my fault, I guess), despite them not being media types technically. So I guess we could be looser in FormatMediaType for symmetry. |
Too late for Go 1.5. |
If you wouldn't mind @rasky, could you provide me with some failing test samples or just values that should be accepted yet are failing? Thanks. |
fmt.Println(mime.ParseMediaType(`attachment; filename="????.png"; filename*=UTF-8''%E6%95%B0%E6%8D%AE%E7%BB%9F%E8%AE%A1.png`))
fmt.Println(mime.FormatMediaType("attachment", map[string]string{"filename": "数据统计.png"}))
fmt.Println(mime.FormatMediaType("attachment", map[string]string{"filename": "test.png"})) |
Seems to be working with current Go (go1.11). |
@andrius4669, does it? https://play.golang.org/p/ndwGaJDMBO4 I see:
@zensh, do you expect the middle case to work? I guess it should encode it with UTF-8 the same way as the first line parses? |
@bradfitz sorry, I didn't meant samples specified by zensh. |
Sorta working on this now. |
Change https://golang.org/cl/154760 mentions this issue: |
On Go 1.4 (darwin),
mime.FormatMediaType
checks whether the first argument (aptly calledmediatype
) contains a forward slash, and returns an empty string if it doesn't. This doesn't allow to use this function to format aContent-Disposition
header, because the values for such header are not proper media types (they are usuallyinline
orattachment
). Notice that the documentation of the reverse functionmime.ParseMediaType
explicitly says that it can be used to parseContent-Disposition
headers, so it looks like this limitation should be lifted.The text was updated successfully, but these errors were encountered: