[OAK-9304] Filename with special characters in direct download URI Content-Disposition are causing HTTP 400 errors from Azure

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.36.0
• Fix Version/s: 1.22.6, 1.38.0
• Component/s: blob-cloud, blob-cloud-azure, blob-plugins
• Assignee: Matt Ryan
• Reporter: Matt Ryan
• Created: 17/Dec/20 21:34
• Updated: 19/Jan/21 07:58
• Resolved: 11/Jan/21 16:07

Description

When generating a direct download URI for a filename with certain non-standard characters in the name, it can cause the resulting signed URI to be considered invalid by some blob storage services (Azure in particular).  This can lead to blob storage services being unable to service the URl request.

For example, a filename of "Ausländische.jpg" currently requests a Content-Disposition header that looks like:

inline; filename="Ausländische.jpg"; filename*=UTF-8''Ausla%CC%88ndische.jpg 

Azure blob storage service fails trying to parse a URI with that Content-Disposition header specification in the query string.  It instead should look like:

inline; filename="Ausla?ndische.jpg"; filename*=UTF-8''Ausla%CC%88ndische.jpg 

 

The "filename" portion of the Content-Disposition needs to consist of ISO-8859-1 characters, per https://tools.ietf.org/html/rfc6266#section-4.3 in this paragraph:

The parameters "filename" and "filename*" differ only in that "filename*" uses the encoding defined in RFC5987, allowing the use of characters not present in the ISO-8859-1 character set ISO-8859-1.

Note that the purpose of this ticket is to address compatibility issues with blob storage services, not to ensure ISO-8859-1 compatibility.  However, by encoding the "filename" portion using standard Java character set encoding conversion (e.g. Charsets.ISO_8859_1.encode(fileName)), we can generate a URI that works with Azure, delivers the proper Content-Disposition header in responses, and generates the proper client result (meaning, the correct name for the downloaded file).