The problem: http status codes 201, 202, etc. which are used in same APIs along with some useful response data, cannot be implemented.
The digging: Response class tries to use connection's error stream in all cases except http status 200. As per SO the error stream is only available if there was a connection which resulted in exception and some data was received.
The solution: Two possibilities are available, implement the logic when the error stream is available or rely on it's availability. The second approach is implemented in the pull request.
Some explanation: The new code tries to use the error stream first, and if it is not available (no error happened) then uses the input stream. This approach relies on the connection to correctly return error stream only in the case where there was error.
How to test: Try to read the response from this API
The problem: http status codes 201, 202, etc. which are used in same APIs along with some useful response data, cannot be implemented.
The digging: Response class tries to use connection's error stream in all cases except http status 200. As per SO the error stream is only available if there was a connection which resulted in exception and some data was received.
The solution: Two possibilities are available, implement the logic when the error stream is available or rely on it's availability. The second approach is implemented in the pull request.
Some explanation: The new code tries to use the error stream first, and if it is not available (no error happened) then uses the input stream. This approach relies on the connection to correctly return error stream only in the case where there was error.
How to test: Try to read the response from this API