OkHttpClient throws illegalStateException when sever sends 100-continue responses prior to the actual response

[londonCyclist]

OKHttpClient (4.12.0) crashes with illegalStateException when the server sends a 100-Continue response before the actual response; this bug is similar to #3628;

Details of this issue are specified in https://stackoverflow.com/questions/79567656/okhttpclient-throws-illegalstateexception-when-server-responds-with-100-continue

Tested it on three different clients using the same server , all of them handles 100-continue responses from server when the clients are not expecting 100-continue response (i.e when expect 100-continue is not specified in the header , the client would just ignore the 100-continue response from server and wait for actual response ).

Expected behaviour would be, OkHttpClient to gracefully handle a 100-continue response from a server without crashing.

[yschimke]

Is this likely fixed by #8569 ?

[londonCyclist]

tested using the latest master, and it appears issue is still present

[yschimke]

IllegalStateException is definitely wrong.

But I'm not sure OkHttp should ignore multiple 100 responses. It seems like a badly behaved server. https://stackoverflow.com/questions/22818059/several-100-continue-received-from-the-server

Would an IOException be appropriate?

[londonCyclist]

I think that spec might be outdated.. The only requirement on the server side is " A server that sends a 100 (Continue) response MUST ultimately send a final status code, once it receives and processes the request content, unless the connection is closed prematurely."
Most of the clients , including Curl would safely discard 100-continue responses from the server until final response code is received. (https://www.rfc-editor.org/rfc/rfc9110.html#status.100 )

[yschimke]

It's actually fixed by #8569 already

Adding a test just to make sure it's covered #8762

[yschimke]

The 4.x branch still needs a fix. Attempting on #8763 but still failing one case

[londonCyclist]

Did a quick manual test on the latest master branch with your commit, issue appears to be fixed .. thanks. Will it be backported to 4.x branch.

[yschimke]

Yes, but will need some more work on that CL