[jira] [Commented] (OAK-9304) Filename portion of direct download URI Content-Disposition should be ISO-8859-1 encoded
[
https://issues.apache.org/jira/browse/OAK-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17258613#comment-17258613
]
Matt Ryan commented on OAK-9304:
{quote}"a umlaut" *is* inside ISO-8859-1.
{quote}
I probably need to remove the mention of ISO-8859-1 as I think this is just
confusing the issue.
The issue is, Azure's blob storage service can't process the URIs if the
filename has characters like this in the name. The fix implemented for this
issue resolves that.
Since the purpose of {{oak-blob-cloud-azure}} is to work with Azure's blob
storage service, I felt it was appropriate to make the change I made so that it
actually does work with Azure in this case.
Here's the relevant diff showing the primary code change for this bug:
{noformat}
private String formatContentDispositionHeader(@NotNull final String
dispositionType,
@NotNull final String fileName,
@Nullable final String
rfc8187EncodedFileName) {
+ String iso_8859_1_fileName =
+new String(Charsets.ISO_8859_1.encode(fileName).array()).replace("\"",
"\\\"");
return null != rfc8187EncodedFileName ?
- String.format("%s; filename=\"%s\"; filename*=UTF-8''%s",
-dispositionType, fileName, rfc8187EncodedFileName) :
- String.format("%s; filename=\"%s\"", dispositionType, fileName);
+ String.format("%s; filename=\"%s\"; filename*=UTF-8''%s",
+ dispositionType, iso_8859_1_fileName,
rfc8187EncodedFileName) :
+ String.format("%s; filename=\"%s\"",
+ dispositionType, iso_8859_1_fileName);
} {noformat}
Note, really all that was added was to do
{{Charsets.ISO_8859_1.encode(fileName)}} to convert the filename, e.g from "a
umlaut" to "a ?".
> Filename portion of direct download URI Content-Disposition should be
> ISO-8859-1 encoded
>
>
> 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
>
> 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}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9304) Filename portion of direct download URI Content-Disposition should be ISO-8859-1 encoded
[
https://issues.apache.org/jira/browse/OAK-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17258444#comment-17258444
]
Julian Reschke commented on OAK-9304:
-
I still don't get it.
"a umlaut" *is* inside ISO-8859-1.
And what you call "encode" seems to be mangling it into "a?".
It would be helpful if you could paste in the actual code points we're talking
about; maybe Jira is the culprit here?
> Filename portion of direct download URI Content-Disposition should be
> ISO-8859-1 encoded
>
>
> 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
>
> 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}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9304) Filename portion of direct download URI Content-Disposition should be ISO-8859-1 encoded
[
https://issues.apache.org/jira/browse/OAK-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17258433#comment-17258433
]
Matt Ryan commented on OAK-9304:
Sure thing [~reschke]. Sorry, I've been on holidays :)
PRIOR TO THIS FIX: When Oak would attempt to generate a direct binary access
URI for a filename with characters outside the ISO-8859-1 character set, this
would result in a URI that Azure would reject with a 400-level error. The
reason was due to Oak failing to properly encode this filename in the
"filename" portion of the Content-Disposition header specification.
(As background, remember that Oak declares to the cloud storage the value that
should be used in the Content-Disposition header for requests to the generated
direct binary access URI. In Oak we specify both the content disposition type
and filenames for this. See [0] and [1] for more info.)
Example: Suppose the filename is "umläut.jpg". Oak would specify a
Content-Disposition header value of:
{noformat}
inline; filename="umläut.jpg"; filename*=''umla%CC%88ut.jpg{noformat}
This is then specified in a query parameter in the direct access URI, so this
information gets encoded. It is probably this encoding change that Azure does
not expect. Since this portion of the URI is signed, the signature doesn't
match and the request fails.
WITH THIS FIX: A basic ISO-8859-1 encoding is done on the "filename" value of
the header. This was made based on RFC6266 Section 4.3 which seems to suggest
that only ISO-8859-1 characters are allowed for that value.
Thus the header now looks like this:
{noformat}
inline; filename="umla?ut.jpg"; filename*=''umla%CC%88ut.jpg{noformat}
This header encodes and validates properly with Azure. In testing, modern
clients prefer the "filename*" portion, which results in the proper filename
being used.
Please let me know if this is still unclear.
[0] -
[https://jackrabbit.apache.org/oak/docs/features/direct-binary-access.html]
[1] -
[https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/api/binary/BinaryDownloadOptions.html]
> Filename portion of direct download URI Content-Disposition should be
> ISO-8859-1 encoded
>
>
> 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
>
> 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}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9304) Filename portion of direct download URI Content-Disposition should be ISO-8859-1 encoded
[
https://issues.apache.org/jira/browse/OAK-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17258116#comment-17258116
]
Julian Reschke commented on OAK-9304:
-
I would still like to see a bug description that I understand.
> Filename portion of direct download URI Content-Disposition should be
> ISO-8859-1 encoded
>
>
> 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
>
> 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}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9304) Filename portion of direct download URI Content-Disposition should be ISO-8859-1 encoded
[
https://issues.apache.org/jira/browse/OAK-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17258102#comment-17258102
]
Marcel Reutegger commented on OAK-9304:
---
bq. This bug has existed in Oak since Oak 1.10. Do we need to backport to
older supported versions, and if so, which?
The Oak 1.10 branch is not supported/maintained anymore. It was superseded by
the 1.22 maintenance branch. I think it would make sense to backport it to that
branch. Users affected by this issue would then have to upgrade to 1.38.0 or
1.22.x.
> Filename portion of direct download URI Content-Disposition should be
> ISO-8859-1 encoded
>
>
> 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
>
> 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}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9304) Filename portion of direct download URI Content-Disposition should be ISO-8859-1 encoded
[
https://issues.apache.org/jira/browse/OAK-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17252128#comment-17252128
]
Julian Reschke commented on OAK-9304:
-
I would still like to see a bug description that I understand :-)
> Filename portion of direct download URI Content-Disposition should be
> ISO-8859-1 encoded
>
>
> 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
>
> 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}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9304) Filename portion of direct download URI Content-Disposition should be ISO-8859-1 encoded
[
https://issues.apache.org/jira/browse/OAK-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17252033#comment-17252033
]
Matt Ryan commented on OAK-9304:
This bug has existed in Oak since Oak 1.10. Do we need to backport to older
supported versions, and if so, which?
If we do not backport, the risk is that users on older versions of Oak may run
into this bug. The bug is, if requesting a direct download URI from Oak for a
filename containing characters outside the ISO-8859-1 character set, users may
find that the resulting direct download URI does not work with certain blob
storage services.
> Filename portion of direct download URI Content-Disposition should be
> ISO-8859-1 encoded
>
>
> 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
>
> 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}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9304) Filename portion of direct download URI Content-Disposition should be ISO-8859-1 encoded
[
https://issues.apache.org/jira/browse/OAK-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17252032#comment-17252032
]
Matt Ryan commented on OAK-9304:
Fixed in Oak trunk in
[r1884613|https://svn.apache.org/viewvc?view=revision=1884613].
> Filename portion of direct download URI Content-Disposition should be
> ISO-8859-1 encoded
>
>
> 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
>
> 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}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9304) Filename portion of direct download URI Content-Disposition should be ISO-8859-1 encoded
[
https://issues.apache.org/jira/browse/OAK-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17251501#comment-17251501
]
Julian Reschke commented on OAK-9304:
-
[~mattvryan] - I don't really get what the ticket says. The first of the two
entries looks perfectly ok to me.
Re double quotes: they are ASCII characters, so no "transposition" is needed.
You can either use quoted-string escaping:
filename="my\"file.txt"
or use the RFC 5978 encoding:
filename*=UTF-8''my%22file.txt
> Filename portion of direct download URI Content-Disposition should be
> ISO-8859-1 encoded
>
>
> 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
>
> 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}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9304) Filename portion of direct download URI Content-Disposition should be ISO-8859-1 encoded
[
https://issues.apache.org/jira/browse/OAK-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17251456#comment-17251456
]
Matt Ryan commented on OAK-9304:
I have an implementation in place for this. You can see the diff here:
[https://github.com/apache/jackrabbit-oak/compare/trunk...mattvryan:OAK-9304]
However, one use case is not passing. That use case is a filename with a
single double-quote in the middle of the filename, like {{my"file.txt}}.
Azure's blob storage service seems to be okay with this but S3 doesn't like it
and returns a 400 response when you try to issue a request with a URI that has
this filename in the query parameters.
Java's ISO-8859-1 encoder doesn't transpose the " character. But IIUC this
filename is a legal filename in Oak.
My question is, should I move forward with the fix I have so far? It is
probably better than what's in trunk. Or do we first need to address the issue
of double-quotes in the filename - and if so, how to address it?
One option would be to search and replace " with %22, which is what is used in
the RFC-8187 encoding for the other filename value in the content disposition.
While not technically the correct value, it would probably work.
Note that both Azure and S3 do support a file with two double-quotes. For
example, if you name the file {{"myfile.txt"}} (with the double-quotes as a
part of the filename), this appears to work, although it might be working by
accident.
> Filename portion of direct download URI Content-Disposition should be
> ISO-8859-1 encoded
>
>
> 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
>
> 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}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9304) Filename portion of direct download URI Content-Disposition should be ISO-8859-1 encoded
[
https://issues.apache.org/jira/browse/OAK-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17251351#comment-17251351
]
Matt Ryan commented on OAK-9304:
[~reschke] I would very much appreciate a review of the bug description as I've
written it, to see if I've interpreted the RFC correctly in this case.
> Filename portion of direct download URI Content-Disposition should be
> ISO-8859-1 encoded
>
>
> 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
>
> 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}
> attachment; filename="Ausländische.jpg";
> filename*=UTF-8''Ausla%CC%88ndische.jpg {noformat}
> It instead should look like:
> {noformat}
> attachment; filename="Ausla?ndische.jpg";
> filename*=UTF-8''Ausla%CC%88ndische.jpg {noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
