[
https://issues.apache.org/jira/browse/HDFS-7816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329790#comment-14329790
]
Jason Lowe commented on HDFS-7816:
----------------------------------
I don't think we can rely on clients changing the way the URL is encoded,
otherwise we break compatibility with older clients.
I think Kihwal's patch will work even with older clients. My main concern is
that we're relying on QueryStringDecoder#path to give us a raw path so URI can
decode it properly. The javadoc for that method says it returns a decoded
path, and if that were ever fixed to match the javadoc then we'd end up
double-decoding which will break for some paths. It also seems weird to me
that we're using a QueryStringDecoder to obtain parts of the URL that aren't
query strings. I think it would be safer to avoid QueryStringDecoder
altogether for the path computation and just pass the original request URI
string to the URI constructor for path decoding.
> Unable to open webhdfs paths with "+"
> -------------------------------------
>
> Key: HDFS-7816
> URL: https://issues.apache.org/jira/browse/HDFS-7816
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: webhdfs
> Affects Versions: 2.7.0
> Reporter: Jason Lowe
> Assignee: Kihwal Lee
> Priority: Blocker
> Attachments: HDFS-7816.patch, HDFS-7816.patch
>
>
> webhdfs requests to open files with % characters in the filename fail because
> the filename is not being decoded properly. For example:
> $ hadoop fs -cat 'webhdfs://nn/user/somebody/abc%def'
> cat: File does not exist: /user/somebody/abc%25def
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
