Response toString()-method behaves differently based on loglevel

[bushwakko]

When calling toString() on the response-object (e.g. as part of error-logging) the behavior differs based on the loglevel on the client-interface. If the loglevel is DEBUG the Response.toString() prints both headers and body correctly, while if it's INFO, the header is printed, but the body is printed as "InputStreamBody@hashCode". I believe this is because with DEBUG enabled the request and response is printed by feign at call-time and this reads the InputStreamBody. Since an InputStream is "used" once read, a new copy of the Response-object is created, this time with the body as ByteArrayBody instead.

The issue is then that the toString() for InputStreamBody is not overloaded.

One solution would be to implement a toString for InputStreamBody that reads the stream, prints it and either replace the body with a fresh InputStreamBody or a ByteArrayBody. It does seem ugly that a toString() would mutate the object like that though and it could possibly cause some concurrency issues.

Granted, relying on the toString() implementation might not be good practice, however it's a bit surprising to have the code behave differently based on log setup.

[kdavisk6]

@bushwakko

Thank you for bringing this to our attention. My first impression is that this feature is not used a lot by the community and this test case is something we've missed. I've marked this issue as a "bug" and "help wanted". If you, or any other contributor has time, we would appreciate a PR to help address this.

[tomdaly]

Hi @kdavisk6, I think I have a fix for this. Will create a PR.