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

[robert engels]

On Fri, 19 Apr 2024 18:28:19 GMT, robert engels <duke at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/sun/net/httpserver/FixedLengthOutputStream.java line 68:
>> 
>>> 66:         remaining --;
>>> 67:         if(remaining==0) {
>>> 68:             close();
>> 
>> `close()` has the side effect of closing the input stream. This again may break other code.
>
> We can remove this. As I stated, it is a bad bug and will leave the connection in a corrupted state if the handler does not call close() on the outstream or the exchange, so I don't think existing code "works".
> 
> Also, I think issuing the close() here is benign, because any further writes would throw an exception (too much data), and a subsequent close (or multiple closes) are ignored.
> 
> Essentially, once you have written all of the data you stated you would send, it is a critical error if you do anything on the output stream other than flush() or close(). I added a check that a flush() on a closed stream is ignored.

as to the input stream being closed, that already would have happened. If the handler closed the output stream, then tried to read the input stream, it would fail.

in retrospect, I think this should be removed, because if the handler was not closing the output stream before, the connection would have been dead, so it seems doubtful this was the case in the field. and then we can fix the broken tests to not not have a bug in not properly closing the output stream.

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

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