Happy to jump on the phone do chat about this. following some answers.
> A lot of standard services support secure and non-secure ports. A deployment might choose to support both http and https. Depending on what an application is accessing the service for, an app can choose to use secure or insecure.
Serving the same content over unsecure/secure endpoints without any control does not make sense and I would say we should prevent it because it would give users a false sense of security.
> Currently uses http port for https
I don't see this a reason for removing. This is exactly what the hadoop.ssl.enable property aims to do, to make sure all HTTP traffic goes over SSL (HTTPS).
> This configuration is not backward compatible and is in conflict with the existing configuration by adding multiple ways to do the same thing.
Unless I'm missing something, previously you could use SSL only for httpfs, that was the reason of the secure port.
Also, you can still set dfs.https.enable without setting hadoop.ssl enable. This is the old behavior. How is this backwards incompatible.
> Per project control to enforce policy is required instead of one global flag.
This is great improvement, however I don't see reverting this JIRA as a requirement for this.
> We want to support both http and https. With redirect from http to https options,
migration to the new setting does not require the applications to change the URL they are currently using.
This is an improvement too and it can be done without reverting this JIRA.