[
https://issues.apache.org/jira/browse/JCLOUDS-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16612450#comment-16612450
]
Rami Hänninen commented on JCLOUDS-1447:
----------------------------------------
I can agree on that the vast majority of jclouds users are probably native
english speakers, or at least their work environment is very oriented towards
english. I can also agree that typical file paths and names rarely contain any
"unsafe" characters because support from surrounding infrastructure discourages
their use. Technical people have to transliterate text daily because
information technology infrastructure has traditionally been so focused on
english. From this perspective, this issue is probably indeed minor.
However, it's a wide world out there, with a lot of people interacting daily
with names, including file names, that contain characters outside the
traditional "safe" character set (a subset of ASCII). Take this from a guy with
a surname that contains one such character (ä). In my humble opinion, modern
serious data processing tools should consider Unicode support as a fundamental
core requirement, and any failures to handle Unicode content should rather be
treated like critical faults, or even blockers, instead of as minor issues.
My final argument is that this is not even a big or complex issue to fix.
Amazon S3 already provides full Unicode support, and supposedly many other
vendors do, too. It is therefore odd to see a middleware tool like jclouds
stand in the way between major services that provides Unicode support, and
those who would like to make use of it. There is also apparently already a
decent pull request waiting, and I actually already did a local fork that fixes
this issue for my use case, too, so I should know how hard this issue was to
fix. Or wasn't. Most of the time went to figuring out how jclouds internal
works. For anyone who already knows this, this issue should be really trivial
to fix.
If after these arguments you still wish to consider this to be a minor issue,
you are of course entitled to do so. However, I would still respectfully
request some reconsideration on the importance of Unicode, and of all
internationalization technologies in general, in the name of everybody who need
to deal daily with characters like 'ä'.
> S3 CopyObject requires x-amz-copy-source to be URL encoded
> ----------------------------------------------------------
>
> Key: JCLOUDS-1447
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1447
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
> Affects Versions: 2.1.1
> Reporter: David Currie
> Assignee: Andrew Gaul
> Priority: Minor
> Labels: s3
> Fix For: 2.2.0, 2.1.2
>
>
> S3 CopyObject requires x-amz-copy-source to be URL encoded as per
> [https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html.]
> Current failure to do so results in a 400:
> {code}
> org.jclouds.aws.AWSResponseException: request PUT
> https://cloudbees-kubernetes-arch.s3.amazonaws.com/jclouds-test/…/test0/2/artifacts/otherdir/xxx%23%3F:%24%26%27%22%3C%3E%C4%8D%E0%A5%90
> HTTP/1.1 failed with code 400, error: AWSError\{requestId='…',
> requestToken='…', code='InvalidArgument', message='Unsupported copy source
> parameter.',
> context='{ArgumentValue=/cloudbees-kubernetes-arch/jclouds-test/…/test0/1/artifacts/otherdir/xxx#?:$&'"<>Äà¥,
> HostId=…, ArgumentName=x-amz-copy-source}'}
> at
> org.jclouds.aws.handlers.ParseAWSErrorFromXmlContent.handleError(ParseAWSErrorFromXmlContent.java:75)
> at …
> at org.jclouds.s3.blobstore.S3BlobStore.copyBlob(S3BlobStore.java:324)
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
