[JENKINS-66745] Winstone: http/2 port not backward compatible with pre-ALPN http/1.1 clients

[jenkins-infra-bot]

According to the docs, Jenkins 2.289.3 LTS supports listening on http/2 (when running on Winstone)

http/2 connections technically work, but the http2 port is not backward compatible with pre-ALPN http/1.1 clients.  so it supports ONLY http/2 connections (primarily browsers) and not other older tool version use-cases.

So while my browser works great at hitting Jenkins using http/2, I cannot use my pre-ALPN curl version (on my RHEL7.9 box) or wget, to download any artifacts from my Jenkins http/2 port.   When I try to download an artifact, I end up with a 32-byte file with the text 'invalid_preface' rather than the artifact.   Surprisingly, there is no error reported by curl.  Scenario testing in curl on a RHEL8.4 box (this version of curl supports ALPN) confirms the issue.

This is very limiting, as one needs to open both a http/2 port (for browsers) and http/1.1 port (for curl/wget and other scripting tools that may not support ALPN/http2 yet).   That's the scenario we find ourselves in at the moment.

As far as I can tell, most J2EE runtime environments support http/2 with automatic fallback to http/1.1 when a non-ALPN aware client (like an old curl version) connects.    That way, a server only needs to expose a single port, and it works for both new and old client http versions.

Unfortunately, Jenkins 2.289.3 LTS does not support pre-ALPN clients accessing the http2 port.

I'm not sure where this limitation lies – in Jenkins' configuration of Winstone, or in Winstone itself.   I do know that Jetty itself supports this feature.  (tested in Jetty 10, just using standard jetty modules)

---

Originally reported by srothco, imported from: Winstone: http/2 port not backward compatible with pre-ALPN http/1.1 clients

• status: Open
• priority: Minor
• component(s): winstone-jetty
• resolution: Unresolved
• votes: 0
• watchers: 2
• imported: 2025-11-27

Raw content of original issue

According to the docs, Jenkins 2.289.3 LTS supports listening on http/2 (when running on Winstone)

http/2 connections technically work, but the http2 port is not backward compatible with pre-ALPN http/1.1 clients.  so it supports ONLY http/2 connections (primarily browsers) and not other older tool version use-cases.

So while my browser works great at hitting Jenkins using http/2, I cannot use my pre-ALPN curl version (on my RHEL7.9 box) or wget, to download any artifacts from my Jenkins http/2 port.   When I try to download an artifact, I end up with a 32-byte file with the text 'invalid_preface' rather than the artifact.   Surprisingly, there is no error reported by curl.  Scenario testing in curl on a RHEL8.4 box (this version of curl supports ALPN) confirms the issue.

This is very limiting, as one needs to open both a http/2 port (for browsers) and http/1.1 port (for curl/wget and other scripting tools that may not support ALPN/http2 yet).   That's the scenario we find ourselves in at the moment.

As far as I can tell, most J2EE runtime environments support http/2 with automatic fallback to http/1.1 when a non-ALPN aware client (like an old curl version) connects.    That way, a server only needs to expose a single port, and it works for both new and old client http versions.

Unfortunately, Jenkins 2.289.3 LTS does not support pre-ALPN clients accessing the http2 port.

I'm not sure where this limitation lies – in Jenkins' configuration of Winstone, or in Winstone itself.   I do know that Jetty itself supports this feature.  (tested in Jetty 10, just using standard jetty modules)

• environment: Jenkins 2.289.3 LTS running on java 11.0.12 2021-07-20 LTS

[jenkins-infra-bot]

timja:

• Original comment link
• Raw content of original comment:

  Have you tested with jetty 9? Which is what we use
  

Have you tested with jetty 9? Which is what we use

[jenkins-infra-bot]

srothco:

• Original comment link
• Raw content of original comment:

  I can confirm that with Jetty 9 standalone distribution (on JDK1.8), this also works properly.
  
  I tested these 3 cases:
  
  	
  client sends http2 ALPN header (server uses http2)
  	
  client sends http1.1 ALPN header (server uses http1.1)
  	
  client sends no ALPN header (server uses http1.1)
  
  
  
   I had the following modules enabled when testing: alpn, http2, https, ssl, deploy.
  
  In particular, note the alpn module has the following .ini file text:
  
  
  # --------------------------------------- 
  # Module: alpn
  # Enables the ALPN (Application Layer Protocol Negotiation) TLS extension.
  # --------------------------------------- 
  --module=alpn
  
  ## Overrides the order protocols are chosen by the server.
  ## The default order is that specified by the order of the
  ## modules declared in start.ini.
  # jetty.alpn.protocols=h2,http/1.1
  
  ## Specifies what protocol to use when negotiation fails.
  # jetty.alpn.defaultProtocol=http/1.1
  
  
  I think the last config line is what causes it to choose http/1.1 if the client does not send any ALPN data in its request (which is the case for pre-ALPN clients like old curl/wget implementations).
  

I can confirm that with Jetty 9 standalone distribution (on JDK1.8), this also works properly.

I tested these 3 cases:

• client sends http2 ALPN header (server uses http2)
• client sends http1.1 ALPN header (server uses http1.1)
• client sends no ALPN header (server uses http1.1)

 I had the following modules enabled when testing: alpn, http2, https, ssl, deploy.

In particular, note the alpn module has the following .ini file text:

# --------------------------------------- 
# Module: alpn
# Enables the ALPN (Application Layer Protocol Negotiation) TLS extension.
# --------------------------------------- 
--module=alpn

## Overrides the order protocols are chosen by the server.
## The default order is that specified by the order of the
## modules declared in start.ini.
# jetty.alpn.protocols=h2,http/1.1

## Specifies what protocol to use when negotiation fails.
# jetty.alpn.defaultProtocol=http/1.1

I think the last config line is what causes it to choose http/1.1 if the client does not send any ALPN data in its request (which is the case for pre-ALPN clients like old curl/wget implementations).

[jenkins-infra-bot]

srothco:

• Original comment link
• Raw content of original comment:

  I can confirm this is a Winstone issue.
  
  I was able to resolve it by editing  src/main/java/winstone/Http2ConnectorFactory.java
  
  and changing this line:
              alpn.setDefaultProtocol("h2");
  
  to this:
              alpn.setDefaultProtocol("http/1.1");
  
  then building a custom winstone and bundling it inside Jenkins.war.
  
  This appears to fix this issue (at least in my testing), because pre-ALPN clients (such as http/1.1) do not send a ALPN header.
  
  The alpn.setDefaultProtocol() method is intended for this specific case, and tells Jetty what protocol to presume the client is sending.
  
  In my testing, this worked properly in all scenarios:
  
  
  ### setup /my/lib with the following files (testing with Jenkins 2.332.3 LTS):
  conscrypt-uber-2.5.1.jar
  jetty-alpn-java-server-9.4.43.v20210629.jar
  
  ### config winstone to listen on http2 port (though it listens for both http2 and http1.1 traffic):
  cat > ./winstone.properties <<EOF
  extraLibFolder=/my/lib
  httpPort=-1
  httpsPort=-1
  http2Port=443
  httpsKeyStore=/my/certs/jenkins.jks
  httpsKeyStorePassword=somepass12345
  EOF
  
  ### start server with winstone.properties
  java -jar jenkins.war
  
  ### run some tests (requires a recent curl version which supports ALPN)
  
  ### test http2 ALPN header:
  curl -v --http2 https://mybox.com:443/job/hello/1/artifact/tnow.txt
  
  ### test http/1.1 ALPN header (unusual):
  curl -v --http1.1 https://mybox.com:443/job/hello/1/artifact/tnow.txt
  
  ### test http/1.1 with no ALPN header (common http/1.1 case with old curl/wget versions):
  curl -v --no-alpn https://mybox.com:443/job/hello/1/artifact/tnow.txt
  
  
  

I can confirm this is a Winstone issue.

I was able to resolve it by editing src/main/java/winstone/Http2ConnectorFactory.java

and changing this line:
alpn.setDefaultProtocol("h2");

to this:
alpn.setDefaultProtocol("http/1.1");

then building a custom winstone and bundling it inside Jenkins.war.

This appears to fix this issue (at least in my testing), because pre-ALPN clients (such as http/1.1) do not send a ALPN header.

The alpn.setDefaultProtocol() method is intended for this specific case, and tells Jetty what protocol to presume the client is sending.

In my testing, this worked properly in all scenarios:

### setup /my/lib with the following files (testing with Jenkins 2.332.3 LTS):
conscrypt-uber-2.5.1.jar
jetty-alpn-java-server-9.4.43.v20210629.jar

### config winstone to listen on http2 port (though it listens for both http2 and http1.1 traffic):
cat > ./winstone.properties <//mybox.com:443/job/hello/1/artifact/tnow.txt

### test http/1.1 ALPN header (unusual):
curl -v --http1.1 https://mybox.com:443/job/hello/1/artifact/tnow.txt

### test http/1.1 with no ALPN header (common http/1.1 case with old curl/wget versions):
curl -v --no-alpn https://mybox.com:443/job/hello/1/artifact/tnow.txt

[jenkins-infra-bot]

srothco:

• Original comment link
• Raw content of original comment:

  I'm not sure the current default protocol setting of 'h2':
     alpn.setDefaultProtocol("h2");
  
  offers any benefit – from my perspective, the only time a client would not send ALPN is the case where the client is http 1.1 – and in that case, the client cannot grok the server's response with the default protocol is set to http/2, as the current default protocol is doing.
  

I'm not sure the current default protocol setting of 'h2':
alpn.setDefaultProtocol("h2");

offers any benefit – from my perspective, the only time a client would not send ALPN is the case where the client is http 1.1 – and in that case, the client cannot grok the server's response with the default protocol is set to http/2, as the current default protocol is doing.

[jenkins-infra-bot]

timja:

• Original comment link
• Raw content of original comment:

  Would you like to send that as a pull request to winstone?
  

Would you like to send that as a pull request to winstone?

[jenkins-infra-bot]

srothco:

• Original comment link
• Raw content of original comment:

  Sure; submitted [JENKINS-66745] Winstone: http/2 port not backward compatible with ALPN http/1.1 clients #226 for this fix.  (This is my first time submitting – hopefully I did it properly.)
  

Sure; submitted #226 for this fix. (This is my first time submitting – hopefully I did it properly.)