Thanks @lucamac

As a side note, I upgraded to this patch (thanks!) and my BinaryResponseHttpHandlers totally failed.

I'd overridden onFailure(Throwable, byte[]), which was originally called before this patch, and it never ended up getting called because this new method now calls the superclass's onFailure(Throwable, String).

I see now that the onFailure(Throwable, byte[]) is deprecated, but as far as I know, overriding a deprecated method doesn't cause a compiler warning. Hence, when I upgraded, I was rather surprised. Can we just remove onFailure(Throwable, byte[]) entirely if it's never going to get called? I think that'd be less of a pain than having everyone find out on their own that their handler isn't getting called.

Thanks again for the library and the fix!

I had got NullPointerException on that line, maybe because in some cases, response[1] is null!
I am yet to replicate the situation but it did happen!

Oh, I agree. I was getting that error, too, and the patch does fix it.

My point is that the fix calls a different error handling method than it did before, which was very unexpected for me as an end-user.

I think it won't solve the problem, since response[1] is null and doing a response[1].toString() will also result in a NullPointerException. Isn't it?

I'm not sure what you're saying. I agree that this patch is necessary to avoid the NPE.

What I'm saying is that it now silently calls a different handler that the programmer may not have written (and has no reason to believe that he should have written), which is rather confusing.

AH! I got what you said. I agree that there should have been a mention about the handleFailureMessage(...) call change. :)

I saw this patch just now and realized that, this patch might not be the solution to the original problem! And it might persist.