I believe the test case is broken. It looks like it assumes that the full sequence is read and handled by curl in a single read, which of course it should not.

Any idea on how to polish this @monnerat ?

Any idea on how to polish this @monnerat ?

Maybe also reject some available data from the stream in libcurl? The tls handshake is always initiated by the client so it should be safe, although useless for normal operations. It may still fail the test however if the data is not yet present (delayed) when the rejection check occurs.

Currently, if pipelined data is not read, it is taken as tls handshake data and then makes the latter failing, which is what we want (although it would have another error code if tls is required).

But there's no support for upgrade to tls in the test server, so I had to use --ssl instead of --ssl-reqd as a workaround.

This test checks pipelining is rejected, but in the target case, curl does not even see it as such and data is processed by the TLS handshake, thus the test is meaningless. The real problem for testing is we can't force curl to read this garbage before the tls handshake.

We surely have the same problem with tests 980, 981 and 983.

The ideal solution would probably to have the buffered data fed into the tls handshake (to "unshuffle" stream data) and the cache check removed: tests for this could then be deleted.