Github user m-hogue commented on the issue:
https://github.com/apache/nifi/pull/1986
@alopresto @jskora : So i mentioned above that there were two reasons why I
opted for this approach. Previous to this PR and confirmed by @alopresto and
@trkurc, the protocol used by ListenHTTP was automatically negotiated with the
client and the configured SSLContextService protocol was ignored. Since the
fact that this is misleading and in an effort to not change processor
communications behavior, i decided to stop the processor on startup if an
invalid protocol was selected and log that the protocol selected wasn't
supported with a recommendation to choose another -- this is evident from the
screenshot i posted above. As pointed out, this will cause processors to break
if they were configured with SSLv3, for example, prior to this change.
Additionally, I didn't want to change the global list of selectable protocols
in SSLContextService if only one (or a few) processor(s) impacted that list.
That's why i attempted to localize the restriction to the one processor.
So instead of breaking the processor if the SSLContextService is configured
with a protocol that isn't supported by ListenHTTP, i see 2 options:
1. If the SSLContextService is configured with something that ListenHTTP
doesn't support, override the protocol to (possibly configured) TLSv1.2 since
that's what it was doing previously and log a warning indicating that this
happened.
2. Build another SSLContextService in which a processor can inform which
protocols should be selectable.
The second is a bit of work and perhaps outside the scope of this issue,
but i'm happy to do whatever is recommended.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
