[
https://issues.apache.org/jira/browse/HDFS-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13465085#comment-13465085
]
Alejandro Abdelnur commented on HDFS-3983:
------------------------------------------
IMO we should use a different scheme (via a new FileSystem client), i.e.
*webhdfss* for the following reasons:
* The URLs themselves will indicate if the resource is served over a secure
transport or not.
* A client may need to communicate with both webhdfs:// and webhdfss://
endpoints, thus a client config will not cut it.
> Hftp should support both SPNEGO and KSSL
> ----------------------------------------
>
> Key: HDFS-3983
> URL: https://issues.apache.org/jira/browse/HDFS-3983
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: security
> Affects Versions: 2.0.0-alpha
> Reporter: Eli Collins
> Assignee: Eli Collins
> Attachments: hdfs-3983.txt, hdfs-3983.txt
>
>
> Hftp currently doesn't work against a secure cluster unless you configure
> {{dfs.https.port}} to be the http port, otherwise the client can't fetch
> tokens:
> {noformat}
> $ hadoop fs -ls hftp://c1225.hal.cloudera.com:50070/
> 12/09/26 18:02:00 INFO fs.FileSystem: Couldn't get a delegation token from
> http://c1225.hal.cloudera.com:50470 using http.
> ls: Security enabled but user not authenticated by filter
> {noformat}
> This is due to Hftp still using the https port. Post HDFS-2617 it should use
> the regular http port. Hsftp should still use the secure port, however now
> that we have HADOOP-8581 it's worth considering removing Hsftp entirely. I'll
> start a separate thread about that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
