[vharseko]

Problem

AMCRLStoreDpFetchTest.theParametersDroppedAtASeeOtherStayDroppedForTheRestOfTheChain fails at random in build-maven (windows-latest, 11) with but was: null (master run 39647411735, attempt 2; #1201 run 40639954288).

The test POSTs to TestHttpServer.redirectTo, which answers with sendResponseHeaders(status, -1) without reading the request body. On JDK 11 the server does not drain the body in that case, and closes the connection with the body still unread, which resets it. On Windows the reset discards the response the client has already received. JDK 17 and later drain the body there.

Changes

• TestHttpServer.redirectTo and redirectAfter read the request body before answering. Every test that POSTs to a redirector goes through one of them.

Verification

• A probe on macOS sends the request headers and the body in two writes, as HttpURLConnection does, to a handler that answers 303 with -1:

	JDK 11	JDK 17
body not read (master)	Connection reset after the response	connection kept alive
body read (this change)	connection kept alive	connection kept alive

macOS hands over the response before the reset, so the failure itself does not reproduce there; it has been seen only on windows-latest with JDK 11, in the two runs above.

• mvn -pl openam-certs test with JDK 11: 148 tests, 0 failures.

Fixes #1208

[maximthomas]

praise: The drain sits exactly where the reset comes from, and it reaches every test that POSTs to a redirector.

• TestHttpServer.redirectTo(int, String) and redirectAfter now read the body before sendResponseHeaders(status, -1). A raw-socket probe on JDK 11.0.25 shows the effect: after a 303 to an unread POST the server closes the connection (second request: Broken pipe, 3/3). Once the body is read, the connection stays open. The source agrees: ExchangeImpl queues WriteFinishedEvent on the -1 path, and ServerImpl closes the connection when !is.isEOF().
• Every POST to a redirector in AMCRLStoreDpFetchTest (storeWithUriParams, lines 387-482, including the two wrapped in recording(...)) goes through redirectTo. The two inline 302 handlers at lines 181-205 only ever get body-less GETs from newStore().