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

[robert engels]

On Mon, 22 Apr 2024 18:52:00 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

>> 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?

I’ll update the PR to fix the tests. I understand the need for backwards compatibility- it’s one of the prime reasons Java is awesome - but in this situation the tests are validating that 1+1=3 and I don’t think anyone wants that. 

You’re assuming that changing the validation of the test cases means the potential for breaking code - as I’ve stated before I don’t think that’s possible in this case - because the test cases were never verifying code you would see in a production system.

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

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