[
https://issues.apache.org/jira/browse/JCR-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz resolved JCR-5255.
---------------------------------------
Resolution: Abandoned
> 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
> Priority: Major
>
> 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)
