DefaultResponseErrorHandler calls Reader#read without checking its return value. It assumes that Reader#read fills as much of the buffer as possible however the API contract makes no such guarantees.

Comment From: sbrannen

Hi @marschall,

Have you encountered a scenario in practice when the read did not consume maxChars characters from the responseBody? If so, can you please provide a unit test for that scenario?

Or are you suggesting the change based on theory and the desire to ensure that at least maxChars characters are consumed if available?

Comment From: marschall

Have you encountered a scenario in practice when the read did not consume maxChars characters from the responseBody?

No, the current implementation of the involved OpenJDK classes causes that maxChars are read.

Or are you suggesting the change based on theory and the desire to ensure that at least maxChars characters are consumed if available?

Yes, while the current implementation of the OpenJDK classes causes maxChars to be read it is my understanding that this behavior is not guaranteed by the API contract outlined in the method Javadoc.

Comment From: sbrannen

while the current implementation of the OpenJDK classes causes maxChars to be read it is my understanding that this behavior is not guaranteed by the API contract outlined in the method Javadoc.

It's true that the contract in the JDK does not guarantee that the desired number of characters will be read into the supplied CharBuffer. However, the leniency of the contract is intended to cover streaming scenarios for which data may appear on the fly at some point after the read invocation. The concrete implementations in use here are ByteArrayInputStream and InputStreamReader which are effectively using System.arraycopy to copy all available characters (up to maxChars) from the responseBody into our CharBuffer. Since the contents and size of the responseBody (which is a byte[]) are not changing, we do not foresee a way for the desired contents not to be copied in a single read invocation.

In light of that, I am closing this PR.

Thanks anyway!