jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Ryan (Jira)" <j...@apache.org>
Subject [jira] [Updated] (OAK-9304) Filename with special characters in direct download URI Content-Disposition are causing HTTP 400 errors from Azure
Date Tue, 05 Jan 2021 01:35:00 GMT

     [ https://issues.apache.org/jira/browse/OAK-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Matt Ryan updated OAK-9304:
---------------------------
    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.

The "filename" portion of the Content-Disposition needs to be ISO-8859-1 encoded, per [https://tools.ietf.org/html/rfc6266#section-4.3]
in this paragraph:
{quote}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.
{quote}
This is not usually a problem, but if the filename provided contains non-standard characters,
it can cause the resulting signed URI to be invalid.  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:
{noformat}
inline; filename="Ausländische.jpg"; filename*=UTF-8''Ausla%CC%88ndische.jpg {noformat}
It instead should look like:
{noformat}
inline; filename="Ausla?ndische.jpg"; filename*=UTF-8''Ausla%CC%88ndische.jpg {noformat}
 

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:
{quote}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.
{quote}
By encoding the "filename" portion using standard Java character set encoding conversion (e.g.
{{ 

  was:
The "filename" portion of the Content-Disposition needs to be ISO-8859-1 encoded, per [https://tools.ietf.org/html/rfc6266#section-4.3]
in this paragraph:
{quote}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.
{quote}
This is not usually a problem, but if the filename provided contains non-standard characters,
it can cause the resulting signed URI to be invalid.  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:
{noformat}
inline; filename="Ausländische.jpg"; filename*=UTF-8''Ausla%CC%88ndische.jpg {noformat}
It instead should look like:
{noformat}
inline; filename="Ausla?ndische.jpg"; filename*=UTF-8''Ausla%CC%88ndische.jpg {noformat}
 

 


> Filename with special characters in direct download URI Content-Disposition are causing
HTTP 400 errors from Azure
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: OAK-9304
>                 URL: https://issues.apache.org/jira/browse/OAK-9304
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: blob-cloud, blob-cloud-azure, blob-plugins
>    Affects Versions: 1.36.0
>            Reporter: Matt Ryan
>            Assignee: Matt Ryan
>            Priority: Major
>
> 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.
> The "filename" portion of the Content-Disposition needs to be ISO-8859-1 encoded, per
[https://tools.ietf.org/html/rfc6266#section-4.3] in this paragraph:
> {quote}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.
> {quote}
> This is not usually a problem, but if the filename provided contains non-standard characters,
it can cause the resulting signed URI to be invalid.  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:
> {noformat}
> inline; filename="Ausländische.jpg"; filename*=UTF-8''Ausla%CC%88ndische.jpg {noformat}
> It instead should look like:
> {noformat}
> inline; filename="Ausla?ndische.jpg"; filename*=UTF-8''Ausla%CC%88ndische.jpg {noformat}
>  
> 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:
> {quote}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.
> {quote}
> By encoding the "filename" portion using standard Java character set encoding conversion
(e.g. {{ 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message