-
Notifications
You must be signed in to change notification settings - Fork 38.5k
ContentDisposition.toString() should include both regular and extended filename parameter #29861
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
Comments
While having both parameters sounds like a good idea, I am having difficulty seeing how we can transform any given String into an US-ASCII string for the |
Transliterating this is way out of scope for the ContentDisposition class imho. Options that might work for the regular attribute:
The first option works for me with the latest Chrome and Firefox releases. |
I decided to resolve this by encoding any non-ASCII characters as quoted-printable (RFC 2047), as that seems to be the most common way to do so. Moreover, we already had decoding support for it. |
RFC 2047 is related to MIME/email. Are you sure that this also applies to HTTP? I've never seen a quoted printable HTTP header, nor was I able to find any references to this on the internet. URL-encoding seems to be the commonly used method for filename parameters. Perhaps a quick test to check how a browser treats quoted-printable encoding might be in order. |
As a general remark, non-ASCII That said, RFC 2047 does apply filenames in HTTP Content-Disposition fields. It is supported by Commons File Upload, Firefox, and Chrome. Granted, browsers are looking to drop support in favor of RFC 5987, but it's still supported, also by Spring Framework. In |
The Content-Disposition header generated by ContentDisposition.toString() includes either the regular
filename
parameter or the extendedfilename*
parameter, depending on the value of thecharset
attribute. For backwards compatibilities with older browser it would be preferable to always include the regular parameter, in addition to the extended parameter. This also seems to be what RFC 6266 suggests:RFC 6266, section 4.3:
Many user agent implementations predating this specification do not understand the "filename*" parameter. Therefore, when both "filename" and "filename*" are present in a single header field value, recipients SHOULD pick "filename*" and ignore "filename". This way, senders can avoid special-casing specific user agents by sending both the more expressive "filename*" parameter, and the "filename" parameter as fallback for legacy recipients (see [Section 5] for an example).
RFC 6266, section 5 (Examples):
This example is the same as the one above, but adding the "filename" parameter for compatibility with user agents not implementing [RFC 5987]:
Note: Those user agents that do not support the [RFC 5987] encoding ignore "filename*" when it occurs after "filename".
The text was updated successfully, but these errors were encountered: