Fix: Use BufferedInputStream to inspect HttpResponse error

[klya]

Fixes #1410

[elharo]

I'm not sure this is the best solution for the underlying issue of reading error responses. The whole mark/reset thing is a bit of a kludge. The error response should be more directly accessible in the API.

However this is a small, safe fix that provides a workaround until we can improve the API for this important case.

[elharo]

marginally cleaner to do an if-else

if (returnRawInputStream) {
  content = lowLevelResponseContent;
} else {
  content = new BufferedInputStream(lowLevelResponseContent);
}

This avoids reassigning a local variable which can be confusing and error prone in the long term.

[klya]

I chose this way just because all previous code in this method used this way. lowLevelResponseContent reassigned two times in preceding code.

[elharo]

Probably worth cleaning this up in a separate PR some time, but for now please don't introduce more reassignments

[klya]

done

[klya]

I'm not sure this is the best solution for the underlying issue of reading error responses. The whole mark/reset thing is a bit of a kludge. The error response should be more directly accessible in the API.

Yep. This way pretty awkward. I see alternatives like this:

• Fetching content from HttpResponse and passing it to the HttpUnsuccessfulResponseHandler. Nearly impossible due to braking changes in the HttpUnsuccessfulResponseHandler interface.
• Allowing access to the HttpResponse.content private field. But this is a violation of encapsulation.
• Make another kind of a handler that can wrap HttpResponse.getContent() or the entire HttpResponse. It looks rather complicated to implement and may cause some side-effects.

Can't find a better solution.