On Java 10.0.1 (build 10.0.1+10), the incubating HttpClient has 2 behaviors that I believe are problematic and should either be fixed or documented to better highlight their limitations.
The first concerns customized Authorization headers. From what I understand, Authorization headers outside of "Basic" are disallowed by the API. For example, when the type of Authorization is set to "Bot" or "Bearer", the following exception is thrown Caused by: java.util.concurrent.CompletionException: java.io.IOException: > Invalid auth header > at > java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367) > at > java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376) > at > java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1074) > at > java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) > at > java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610) > at > java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649) > at > java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > at java.base/java.lang.Thread.run(Thread.java:844) > Caused by: java.io.IOException: Invalid auth header > at > jdk.incubator.httpclient/jdk.incubator.http.AuthenticationFilter.lambda$response$1(AuthenticationFilter.java:211) > at java.base/java.util.Optional.orElseThrow(Optional.java:397) > at > jdk.incubator.httpclient/jdk.incubator.http.AuthenticationFilter.response(AuthenticationFilter.java:210) > at > jdk.incubator.httpclient/jdk.incubator.http.MultiExchange.responseFilters(MultiExchange.java:195) > at > jdk.incubator.httpclient/jdk.incubator.http.MultiExchange.lambda$responseAsyncImpl$7(MultiExchange.java:273) > at > java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072) > ... 7 more Adding the following hack fixes the issue regarding using a "Bot" type (code is in Kotlin). The solution was taken from here: https://clevertap.com/blog/java-9-httpclient-does-not-allow-custom-authorization-headers/ httpRequest.javaClass.getDeclaredMethod("setSystemHeader", > String::class.java, String::class.java).apply { > isAccessible = true // Allows access to an internal method to add > Authorization header for httpRequest > invoke(httpRequest, "authorization", requestHeaders["authorization"]) > } However, "Bearer" still fails with the same exception. Either this restriction should be lifted (I see no reason to restrict it), or add this behavior to the Javadocs. The second issue regards setting an Executor when building a HttpClient. There is problematic behavior regarding it when using an Executor under 1 of 2 scenarios. When an Executor uses the current running thread the request never completes and blocks the current thread. I have not done any in-depth debugging to pinpoint the exact cause. The behavior I expect from this is the thread is blocked as it waits for the request to come through, but it should come through eventually; as if it was a sync API. When an Executor only uses a single thread (more specifically, if I use Executors.newSingleThreadExecutor), the same behavior occurs; except the behavior in this case should clearly be that the work is offloaded to another thread, allowing the application to continue, but it doesn't, it still gets stuck at the request call. I have received an exception before when running on the current thread that relates to some method being invoked on the same thread as another method. However, when retrying these scenarios for this posting, I was unable to replicate this behavior, and thus both Executor scenarios produce the same behavior. Either the Executor behavior should be fixed or its limitations should be documented. Sorry if this post isn't following a specified format typical for mailing listings, I have never participated in one before, but I hope these concerns can be considered.
