build(deps): bump org.apache.httpcomponents.core5:httpcore5 from 5.3.6 to 5.4

[dependabot]

Bumps org.apache.httpcomponents.core5:httpcore5 from 5.3.6 to 5.4.

Changelog

Sourced from org.apache.httpcomponents.core5:httpcore5's changelog.

Release 5.4-alpha1

This is the first ALPHA release in the 5.4 release series that improves HTTP/2 protocol support by ensuring conformance to the latest HTTP specification (RFC 9113) and adds support for Unix domain sockets.

This release also includes all the fixes from the stable 5.3 branch.

Notable changes and features included in the 5.4 series:

• Experimental OFFLOCK (lock-free) connection pool.

• Conformance to RFC 9218 (Extensible Prioritization Scheme for HTTP).

• Improved conformance to RFC 9113 (Hypertext Transfer Protocol Version 2).

• Five-second TCP keep-alive enabled by default.

• Unix domain socket support by the classic and async transports.

• Redesign of classic over async API bridge.

• Improved URI encoding per RFC 3986.

• QUERY method support.

Change Log

• Experimental RouteSegmentedConnPool (OFFLOCK): lock-free, route-segmented, disposal off critical path. Contributed by Arturo Bernal

• Configurable AuthorityResolver for async server bootstraps. Contributed by Christian de Waal

• RFC 9218 HTTP/2 Priority support (#552). Contributed by Arturo Bernal

• Stale connection check for the async protocol handlers. Contributed by Ryan Schmitt

• Corrected JavaDoc for HttpConnection#close to reference correct CloseMode mode (#561). Contributed by Arturo Bernal

• HTTPCORE-785: Improved Javadocs of TlsStrategy implementations. Contributed by Oleg Kalnichevski

... (truncated)

Commits

• 0ca2dde HttpCore 5.4 release
• 5a3e465 Updated release notes for HttpCore 5.4 release
• 69a7663 Fix validation of 0/8 IPv4 addresses
• a70a62c Route-segmented pool: fix timeout race; add direct hand-off; enforce TTL on l...
• b3fc3f3 Ensure connection is closed immediately upon socket timeout
• 729e2a8 H2 Priority example clean-up
• 4e640ff Accept leading zeros in IPv4-mapped IPv6 (#568)
• 030f51f Upgraded HttpCore version to 5.4-alpha2-SNAPSHOT
• 9be094e HttpCore 5.4-alpha1 release
• dfb42f4 Javadoc fix
• Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[jeremylong]

@dependabot rebase

[dependabot]

Looks like this PR has been edited by someone other than Dependabot. That means Dependabot can't rebase it - sorry!

If you're happy for Dependabot to recreate it from scratch, overwriting any edits, you can request @dependabot recreate.

[jeremylong]

@dependabot recreate

[nhumblot]

As of now, 'build and test docker' job is failing

2026-01-30T19:21:32.9588732Z ##[group]Run ./test-docker.sh
./test-docker.sh
shell: /usr/bin/bash -e {0}
Initially creating persistent directory: /home/runner/OWASP-Dependency-Check/data
Initially creating persistent directory: /home/runner/OWASP-Dependency-Check/reports
Initially creating persistent directory: /home/runner/OWASP-Dependency-Check/data/cache
Exception in thread "main" java.lang.NoClassDefFoundError: jdk/net/Sockets
	at org.apache.hc.client5.http.impl.io.DefaultHttpClientConnectionOperator.<clinit>(DefaultHttpClientConnectionOperator.java:87)
	at org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:132)
	at org.owasp.dependencycheck.utils.Downloader.<init>(Downloader.java:143)
	at org.owasp.dependencycheck.utils.Downloader.<clinit>(Downloader.java:123)
	at org.owasp.dependencycheck.App.run(App.java:190)
	at org.owasp.dependencycheck.App.main(App.java:92)
Caused by: java.lang.ClassNotFoundException: jdk.net.Sockets
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:580)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
	... 6 more
Process completed with exit code 1.

Related discussion linked to this error: https://lists.apache.org/thread/5pmyy8xclqwht49gccy3xvnd2pmv2pz4

[chadlwilson]

That's a bad decision on their part IMHO, seems there are more robust solutions available.

Putting that aside, I wonder if it happens on regular Temurin image builds? Possibly, given Temurin is referenced in that issue. That would also be an official library base image which would be better practice than using custom Azul registry images.

[nhumblot]

That's a bad decision on their part IMHO, seems there are more robust solutions available.

Putting that aside, I wonder if it happens on regular Temurin image builds? Possibly, given Temurin is referenced in that issue. That would also be an official library base image which would be better practice than using custom Azul registry images.

I do not believe there is any issue with the Azul JDK from the Azul registry. The current approach—explicitly declaring the modules we use in our Docker image—is a good practice. It reduces the build size and minimizes the attack surface by removing unnecessary modules. Importing the jdk.net module resolves the issue.

The pipeline is now green. I plan to conduct additional tests to assess the potential impact of this change, as I am concerned it might break some user execution setups. In addition to the change itself, I would welcome feedback on what type of release this change should be classified as (patch, minor, or major), based on the information provided.

[chadlwilson]

Oh yes, it's doing custom jlink, I forgot. So that mostly rules out concerns with the base image.

Separately, I think that custom jlink is probably not a good idea either - given the level of automated testing across this project and the analyzers/data sources with their own custom libraries/APIs. This project has a large amount of dependency sprawl making it difficult to reason about the correct modules needed - and probably much higher value to reduce the dependency sprawl than remove more JDk modules. And its more to maintain....

This being discovered seems like luck more than anything.

[dependabot]

A newer version of org.apache.httpcomponents.core5:httpcore5 exists, but since this PR has been edited by someone other than Dependabot I haven't updated it. You'll get a PR for the updated version as normal once this PR is merged.