RFR: 8298588: WebSockets: HandshakeUrlEncodingTest unnecessarily depends on a response body

[Severin Gehwolf]

On Mon, 5 Dec 2022 06:52:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello @Karm,
> 
> > According to [rfc6455](https://www.rfc-editor.org/rfc/rfc6455.html#section-5.5.1), the close frame MAY contain a body, i.e. it is considered [optional](https://www.rfc-editor.org/rfc/rfc2119#section-5). It seems that the contemporary JDK HEAD (tip) does populate the body and thus enables `HandshakeUrlEncodingTest.java` to parse its contents. On the contrary, JDK 11 does not populate the body in the same case. I would like to backport JDK-8245245 all the way to JDK 11, so I would like to change the behavior of this test so as it works across JDK versions.
> 
> I believe the right thing to do here, to help with the backport of this test, is to also backport the actual change/fix which populates the `HttpResponse` body. I think that fix was done as part of https://bugs.openjdk.org/browse/JDK-8240666. So backporting that fix to JDK 11 should allow you to backport even this test case to JDK 11 without any changes to this test case.

Maybe. On the other hand, adding the response to the body of a websocket request is a *behaviour* change, which I find questionable as to being "the right thing to do", considering we are trying to solve an encoding [bug in JDK 11](https://bugs.openjdk.org/browse/JDK-8245245) in a stable release. A bug fix shouldn't have a behaviour changing enhancement as a dependency if at all possible. Would this patch not be acceptable as is? It only encodes what the RFC states (allowing for empty body responses). Would the patch be more amenable if it were add additional body assertions iff the body is present?

-------------

PR: https://git.openjdk.org/jdk/pull/11486