Sylwester Lachiewicz created JCR-5255:
-----------------------------------------
Summary: Upgrade to Apache HttpClient 5
Key: JCR-5255
URL: https://issues.apache.org/jira/browse/JCR-5255
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-spi2dav, jackrabbit-webdav
Reporter: Sylwester Lachiewicz
jackrabbit-webdav and jackrabbit-spi2dav still depend on Apache HttpClient
4.5.14 and HttpCore 4.4.16. Upstream declares that branch end-of-life and
states that "Users of HttpClient 4.x are strongly encouraged to migrate to
HttpClient 5.x" – see [https://hc.apache.org/status.html]
This issue tracks upgrading those modules to HttpClient 5.
This is deliberately narrower than JCR-5122, which proposes replacing Apache
HttpClient with the JDK HTTP client. Upgrading to HttpClient 5 keeps the
capabilities the JDK client lacks – most notably inspection of 1xx responses,
which JCR-5122 records as a blocker for Early Hints and Resumable Uploads –
along with the multipart support that spi2davex uses and the connection
manager, proxy and TLS configuration surface that ConnectionOptions exposes.
The two directions are not mutually exclusive: a 4.x to 5.x upgrade can stand
on its own whether or not a JDK-client-based WebDAV client is added later.
Scope, measured on trunk:
jackrabbit-webdav: 27 production files, but only 9 distinct HttpClient 4 types.
The hard coupling is a single line, BaseDavRequest extends
HttpEntityEnclosingRequestBase.
jackrabbit-spi2dav: 9 production files. This is the substantive work, covering
connection management, authentication, multipart, TLS and proxy configuration.
jackrabbit-jcr-server: no production usage at all; all 11 affected files are
tests.
ConnectionOptions needs no public API change, since the HttpClient types appear
only in its non-public configure method.
The httpmime artifact disappears, since its classes now live in httpclient5 as
org.apache.hc.client5.http.entity.mime.
Behavioural differences that need explicit handling rather than a mechanical
rename:
HttpClient 5 defaults connect, socket and connection-lease timeouts to three
minutes, where HttpClient 4 with the ConnectionOptions value -1 waited
indefinitely. Left unhandled this breaks long observation polls and large batch
operations. Timeout.DISABLED restores the previous behaviour.
HttpClient 5 follows redirects for every method, whereas HttpClient 4
redirected only GET and HEAD. For WebDAV this matters, since a redirected MOVE,
COPY, PUT or DELETE would be followed silently rather than surfaced to the
caller.
HttpClient 5 does not pre-authenticate from a BasicScheme held in the AuthCache
unless it has been primed via initPreemptive.
HttpClient 5 keeps a pooled connection leased until the response is closed or
its entity consumed, including for status-only responses that HttpClient 4
released automatically.
ProxyAuthenticationStrategy no longer exists; proxy authentication goes through
the shared authentication strategy.
HttpHost takes (scheme, host, port) rather than (host, port, scheme),
credentials take a char[] password, and entities are immutable.
Two further points worth recording:
HttpComponents publishes no OSGi bundles for the 5.x line. httpclient5-osgi and
httpcore5-osgi stop at 5.0-beta, and the plain 5.x JARs carry no
Bundle-SymbolicName, so OSGi consumers would have to wrap them themselves.
HttpClient 5 retries the next resolved address after a TLS handshake failure,
because the TLS upgrade sits inside the per-address retry block of
DefaultHttpClientConnectionOperator. On a dual-stack localhost this surfaces an
SSLHandshakeException as a connection failure instead. This looks like an
upstream bug and degrades TLS diagnostics on multihomed hosts generally.
Note that this is a breaking API change for the exported package
org.apache.jackrabbit.webdav.client.methods, as already noted on JCR-5122.
BaseDavRequest changes its base class and constructor signature, and the
response accessors take ClassicHttpResponse in place of HttpResponse. Whether
that is done in place or additively in a new package, following the deprecation
approach discussed on JCR-5122, is open for discussion.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
