Daniel,
I imported the patch from the link you provided as follows:
hg import --no-commit open.patch
The patch applied successfully. I tried then to run the tests and saw that some
of them could not be compiled. For instance,
java/net/httpclient/websocket/BlowupOutputQueue.java
java/net/httpclient/websocket/PendingPingBinaryClose.java
...
etc.
> On 13 Jan 2020, at 13:06, Daniel Fuchs <daniel.fu...@oracle.com> wrote:
>
> Hi,
>
> Please find below a fix for:
> 8236859: WebSocket over authenticating proxy fails with NPE
> https://bugs.openjdk.java.net/browse/JDK-8236859
>
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8236859/webrev.00/
>
> It happens when we have a TLS tunnel and authentication with the server
> fails: in that case the TLS tunnel is not established. The WS logic tries to
> get the RawChannel to close it (as it should) but the debug trace gets in the
> way and causes a NPE.
> If the debug trace is fixed, the NPE occurs later (in connectFlows()).
> The solution is to avoid creating the rawChannel for the sole purpose of
> closing the connection. A new method added to RawChannel.Provider (internal
> API) does the trick.
>
> While investigating this issue I stumbled over several other problems:
> an assertion was occurring in the HTTP/1.1 connection pool, because
> the failed connection was wrongly returned to the pool instead of
> being closed. This will be fixed here two.
>
> Then I stumbled on another issue when both the proxy and the server
> required credentials: the proxy credentials were not added to the cache
> but requested every time because the 407 was followed by a 401, and
> that caused 407 to be returned again at the next round trip, causing
> the request to eventually fail with "too many retries".
> This is now fixed in AuthenticationFilter.
>
> The WebSocketProxyTest.java is now updated to test wss: and to test
> both proxy and server authentication in the same request.
>
> best regards,
>
> -- daniel
