Bug 64493 - Regression: JMX beans for HTTPS connector changed protocol with 9.0.35
Summary: Regression: JMX beans for HTTPS connector changed protocol with 9.0.35
Alias: None
Product: Tomcat 9
Classification: Unclassified
Component: Connectors (show other bugs)
Version: 9.0.35
Hardware: PC Mac OS X 10.1
: P2 normal (vote)
Target Milestone: -----
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2020-06-02 15:03 UTC by asf+paul
Modified: 2020-06-02 16:31 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description asf+paul 2020-06-02 15:03:31 UTC
Using the following pseudo code:

      MBeanServer server = MBeanServerFactory.createMBeanServer();
      Set<ObjectName> protocolHandlers = server.queryNames(new ObjectName("Catalina:type=Connector,*"), null);
      for (ObjectName x: protocolHandlers)
        String protocol = (String) server.getAttribute(x, "protocol");
        System.out.println(x + " - " + protocol);
    catch (Exception e)

Then under 9.0.30 we get:

Catalina:type=Connector,port=10180 - HTTP/1.1
Catalina:type=Connector,port=10443 - HTTP/1.1

Under 0.0.35 we get:

[15:02] Anton Goselink
Catalina:type=Connector,port=10180 - HTTP/1.1
Catalina:type=Connector,port=10443 - org.apache.coyote.http11.Http11NioProtocol

I believe that this is related to https://github.com/apache/tomcat/commit/5e0dd5d91ca3b9eb85d79fca2b9ce9313d90083c , since in the old situation, whenever the connector was Http11NioProtocol, it would return "HTTP/1.1". in the new situation, when a ProtocolHandler is passed in, we use the class name instead of "HTTP/1.1" for configuredProtocol. This should probably get the name of the protocol being handled from the ProtocolHandler.

In any case, this causes a breakage in our environment, as we rely on the protocol being set to "HTTP*" for the JMX bean.
Comment 1 Remy Maucherat 2020-06-02 15:15:48 UTC
Well, the new value is correct as well I'm afraid. I will look at how easy it is to restore the fake value.
Comment 2 asf+paul 2020-06-02 15:19:07 UTC
I would be happy if they _both_ showed the same value, either new or old. It is the mismatch between the two that makes me sad.

Ideally we would keep the old, then we wouldn't need to update our product to get the CVE fix in 9.0.35.
Comment 3 Remy Maucherat 2020-06-02 15:22:15 UTC
The new behavior reflects what is passed to the constructor, which I think is more consistent, so how is your connector created ?
Comment 4 Remy Maucherat 2020-06-02 15:42:25 UTC
I decided to change it back in 9.0.36. 10.0 will continue to use the value that was used to configure the connector.
Comment 5 asf+paul 2020-06-02 16:26:36 UTC
We construct it through server.xml I guess. We don't call this code directly, but rather through the normal tomcat configuration.

Our server.xml has:


which would explain the difference, since the former is converted into the latter in code. Previously the latter was also converted back into the former when exposing the name, whereas now we just use what was passed in (I guess?).

At least this gives a configuration change instead of a code change, so we can deploy a new Tomcat and change config.

Verifying, that changing the second "protocol" to 


Does give us the output that we expect in our code. So now the question is was this a desired side effect of the change? And if not, can this be fixed?
Comment 6 asf+paul 2020-06-02 16:31:01 UTC
Thanks for the change!

As discussed in the previous comment we do have a workaround that we could apply, now that we know what the change is and the reason why this changed. So although I would still argue against this change for the 9.0 branch, since it _might_ require code/config changes for users.