On Mon, 29 May 2023 17:10:14 GMT, Daniel Fuchs <[email protected]> wrote:
> Please find here a fix for the java/net/httpclient/ExpectContinueTest.java
> which was failing intermittently.
>
> It turns out there was two bugs here:
>
> - on on the server side, which added the END_STREAM flag to the HeaderFrame
> containing the 100 response.
> This can obviously never be right since 100 is an intermediary response,
> which should be followed by a final response.
>
> - on the client side, because this was interpreted as "there will be no body"
> - but it didn't prevent the client from waiting for the final response.
>
> With this fix a 100 response carrying the END_STREAM flag will cause the
> exchange to be cancelled. I manually verified that this worked before fixing
> the server side.
>
> The logic on server side is fixed to ignore whatever length is passed to
> sendResponseHeaders() if 100 is supplied, and to not add the END_STREAM flag
> to the HeaderFrame that carries the 100 response (which is a side effect of
> setting the expected length parameter to 0 in that case).
src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 529:
> 527: debug.log("Received 100 statusCode, but FIN bit is
> set");
> 528: }
> 529: cancelImpl(new IOException("stream closed after 100, no
> other response expected"));
This will produce the wrong error code; see
https://datatracker.ietf.org/doc/html/rfc9113#name-http-message-framing :
> An interim response consists of a
> [HEADERS](https://datatracker.ietf.org/doc/html/rfc9113#HEADERS) frame (which
> might be followed by zero or more
> [CONTINUATION](https://datatracker.ietf.org/doc/html/rfc9113#CONTINUATION)
> frames) containing the control data and header section of an interim (1xx)
> HTTP response (see [Section
> 15](https://www.rfc-editor.org/rfc/rfc9110#section-15) of
> [[HTTP](https://datatracker.ietf.org/doc/html/rfc9110)]). A
> [HEADERS](https://datatracker.ietf.org/doc/html/rfc9113#HEADERS) frame with
> the END_STREAM flag set that carries an informational status code is
> [malformed](https://datatracker.ietf.org/doc/html/rfc9113#malformed)
> ([Section 8.1.1](https://datatracker.ietf.org/doc/html/rfc9113#malformed)).
> Malformed requests or responses that are detected MUST be treated as a
> [stream
> error](https://datatracker.ietf.org/doc/html/rfc9113#StreamErrorHandler)
> ([Section
> 5.4.2](https://datatracker.ietf.org/doc/html/rfc9113#StreamErrorHandler)) of
> type
> [PROTOCOL_ERROR](https://datatracker.ietf.org/doc/html/rfc9113#PROTOCOL_ERROR).
as far as I could tell, `cancelImpl` sends `CANCEL` error code.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14207#discussion_r1210132757
