RFR: 6968351: httpserver clashes with delayed TCP ACKs for low Content-Length [v14]

[Daniel Jeliński]

On Mon, 22 Apr 2024 16:30:01 GMT, robert engels <duke at openjdk.org> wrote:

>> I understand what you're saying - but you would be surprised of what you could encounter in the wild. In any case, it's not an issue if no backport is intended.
>
> If I write a test case "test multiple requests without closing" - and add that test case to earlier JDK versions, it will fail every time - with no setting that would allow it to work.
> 
> So trying to protect earlier bad code that couldn't possibly have worked doesn't seem right to me. I am fairly certain that the only existing code that will break are the incorrect tests cases that exist in the JDK. There can be no existing handlers in the wild that will break with these changes.
> 
> I feel like I am taking up too much of your time with these discussions.  I was only trying to fix the jdk version for others (using the knowledge I gained in the robaho impl).
> 
> A back-ported change could guard the changes - they are fairly trivial - but I'll let others undertake that.
> 
> The api [docs](https://docs.oracle.com/en/java/javase/11/docs/api/jdk.httpserver/com/sun/net/httpserver/HttpExchange.html) already state:
> 
>> When the response body has been written, the stream must be closed to terminate the exchange.
> 
> so I don't think back-porting as is an issue. I have never encountered an impl of an api that tries to work around improper use of the api.

Let me add some background:
https://www.hyrumslaw.com/
https://xkcd.com/1172/
https://wiki.openjdk.org/display/csr/Kinds+of+Compatibility

Every time we make an observable behavioral change, we need to decide if we can make it without any additional documentation, or if a release note or a CSR is necessary.

In this case we have 2 failing tests with that change. As you correctly pointed out, these tests are failing because of bugs in their implementation. But then, these tests show that the change is already impacting existing code. With that in mind, a release note will be necessary. This is not for us; this is for the users who may upgrade to the latest version and find that their tests are failing.

The product changes are fine in their current form. Could you fix the failing tests?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1575225497