Evaluate changes in Apache HttpClient 4.4.x/4.5.x

Fyi, I was actually planning on closing this issue out. This is old and we’re already on 4.5.x. I will close and open a new issue for 5.x

AFAIK, we do the etag mgmt ourselves and not at the level of the HttpClient handling it, because the whole point is to bypass the XML processing. The HttpClient's caching support is invisible to callers, you get the document back each time, just possibly skipping the network call. Pretty irrelevant for most of our other use cases.

don't even rely on it in the main place we would need it (the batch resolvers).

Do you mean the eTag stuff? I was pretty sure that we had that, but Brent will put me right. Or do you mean the "not saving the etag when we cache to file" thing?

I wasn't commenting on advantages ror disadvantages. My speculation is that like a lot of the other supplemental pieces we use, Java's inclusion of "something" might ultimately kill off Apache's alternatives, so it was more of a case of "in case we find out we have to".

I didn't note the scope of the SSL configuration was client and not request, though in practice I think it just means more client objects created and managed per component rather than shared across the system. In practical usage, I see that already in my configuration, I don't usually share a general client across much more than one or two extra components due to specialized settings.

Also, I'm not sure we derive much benefit from the conditional GET support. It's fairly confusing now in terms of interactions with our own caching, and we don't even rely on it in the main place we would need it (the batch resolvers). I actually saw not having that as almost a feature.

Just some general notes...

I looked at the Java 11 HttpClient just a bit.  I don't know as much as I need to yet, but based on what I see so far I definitely would not commit to switching to this just yet.

Aside from the general suckiness of the HTTP stuff that has historically come in the JDK, there's several things missing or unclear that concern me.

There doesn't seem to be any notion of passing in custom attributes/properties at runtime (i.e in the send(...) method) to influence how the various plugin interface impls work on a per-call basis.

I see a connection timeout setting on the client, but docs suggest it doesn't cover socket read timeout.  If not, I hope the answer isn't the usual "it's a system property".

Wire trace logging and other debug logging is valuable. Need to confirm what support theirs provides, i.e. java.util.logging which can be handled by SLF4J bridges, etc.  Historically it was often log is enabled and configured via a system property and then stuff goes to stdout/stderr, which is awful.

HttpClient is a class, not an interface, so not as easy to layer custom pre-/post-request processing functionality by layering.

Caching and conditional GET support?

Also, not a problem, but it's all a fluent style, so to support Spring/IoC we'd still need our own custom builder(s) for the client itself and other things mostly. At least, assuming your not supposed to build a new client for every request, that's probably considered expensive.

Scott, I don't know what particular advantage you see to the SSLContext and SSLParameters stuff in the HttpClient.Builder.  The HC builder also exposes setting SSLContext directly, but generally you probably need builder-type stuff around that, at the very least to support Spring/IoC.  In particular it doesn't really solve anything around what we do in our SecurityEnhancedTLSSocketFactory for Apache HC to support per-request trust engine, client TLS key, ciphers, protocols and hostname validator.

In this general vein, we also ought to look at Apache HttpClient v5, which is currently in beta.