HTTP2 Additional Port Handling and Flexibility

Description

When a Commandbox server is started with HTTP2 and additional port binding to 1444 is spawned. The HTTP and/or HTTPS ports serve traffic with HTTP2 capabilitys, however this additional port binding is hard-coded, which means two servers running HTTP2 may not run on the same host - as the second server will not start due to the port conflict.

Allow the HTTP2 port to either be configured or re-use one of the open HTTP/HTTPS ports.

Activity

Show:
Sami Hoda
March 29, 2021, 7:01 PM

Not yet!

Brad Wood
March 29, 2021, 6:59 PM

Did you get a chance to try this?

Brad Wood
March 25, 2021, 7:32 PM

Does using the runwar.undertowOptions instead of “runwar”: {"args":"--http2-enable=true" } not spawn the additional port?

No, because the Runwar arg triggers a chunk of code by a previous Runwar developer which adds that option AND implements a reverse proxy on a separate port, which is code basically copied from the Undertow HTTP2 examples online. The method I showed above enables the same setting, but just directly without any of the reverse proxy stuff.

I directly E-mailed the Undertow Devs from RedHat/JBoss and while I’m still waiting for final clarification, they said the reverse proxy was just a part of the example that’s not actually necessary. A detail which was apparently lost to most of the internet since pretty much every Undertow HTTP2 example you can find online does that same reverse proxy bit copied from the official documentation. I have no clue why on earth they included that in their example, but apparently it’s not actually needed even though the previous Runwar dev tried to put it in.

And since we discussed this internally, the Undertow dev also told me that x-undertow-transport header is NOT part of the core. It’s also just another random part of the example which is not a requirement or an expectation in a production system. it seems it has also just been copied and pasted around the internet since it also appears in every example out there.

If so, that would solve this issue.

The issue of the port, yes. I’d like Sami to do some testing and make sure all the features of HTTP2 are actually in full working order first before we rush to a conclusion that we’re ‘done here’. I’m also waiting back for final clarification like I mentioned above that the reverse proxy is 1000% unnecessary we well.

Also, if so, can we add some syntactic sugar to the HTTPS block ( like a http2 : true setting ) to set this variable under the hood?

Yes, of course. This was always the plan. But until we have a tested method that we know works and I’ve satisfied my questions with the Undertow devs, the feature is still experimental.

In truth, we could enable it by default, as both Apache and NGINX do that now, as well

I agree. Most major browsers will only use HTTP2 over SSL, but from what I’ve seen in Chrome, there’s no downside to having it enabled even over HTTP as the browser seems to just ignore it.

I’ve also been thinking about adding some first-class settings for the HTTP->HTTPS redirect and HSTS just since those seem like pretty common scenarios, even though they’re not difficult to do with a server rule. I already added this ticket:

Jon Clausen
March 25, 2021, 7:15 PM
Edited

does using the runwar.undertowOptions instead of “runwar”: {"args":"--http2-enable=true" } not spawn the additional port?

If so, that would solve this issue. Also, if so, can we add some syntactic sugar to the HTTPS block ( like a http2 : true setting ) to set this variable under the hood?

In truth, we could enable it by default, as both Apache and NGINX do that now, as well ( though not for proxies as those have to be handed by using keepalives )

Brad Wood
March 25, 2021, 7:05 PM

can you try this. Enable HTTPS on the port of your choice and then add this setting only

I just tested this on a local server and if I add the “protocol” column to the Network tab in my Chrome debugger, the requests show as using HTTP2.

Furthermore, since major browsers only support HTTP2 over SSL, I was able to successfully redirect HTTP requests to HTTPS (assuming HTTPS was on port 443) like so:

Or alternatively, I was able to configure HSTS like so (assuming HTTP/HTTPS ports were on 80/443)

Fixed

Assignee

Brad Wood

Reporter

Jon Clausen

Labels

None

Affects versions

None

Fix versions

Priority

Major