square / okhttp

Square’s meticulous HTTP client for the JVM, Android, and GraalVM.

Home Page:https://square.github.io/okhttp/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Make UnreadableResponseBody visible

NicolaVerbeeck opened this issue · comments

In 5.0.0-alpha7 unreadable response bodies are no longer returned as null but instead are an opaque non-readable body. This unreadable body class is also internal. For network inspection tools such as Niddler that have a generic 'read this body' method, we can not check if a response body will be readable or not, only relying on catching the thrown exception.

Suggestion: make UnreadableResponseBody visible again, the alternative would be a field on ResponseBody that indicates if it can be read or not (which adds pollution to the general use API).

How does it even get a reference to these unreadable bodies? They're never the body of tbe response that the application layer interacts with.

   final Response networkResponse = response.networkResponse();

   // Somewhere down the line
   serializeBody(networkResponse.body())

This allows us to inspect the actual network body before it is transformed by other interceptors

If we change it to an IOException, does that work for you? I don't want to make this API public.

I don't think that will change anything, I'd still not be able to check the actual network message's body. I'll just have to create a more involved system that uses 2 interceptors (1 network level and 1 application level) and then figure out a clean way to pass those bodies from network to application interceptor, probably using tags + not try to serialise bodies that will probably be not serialisable.

Just wanted to avoid the 'expensive' exception generation in the simplest case

Reopening - it's something that has observably changes between 4.x and 5.x so we should agree a plan, or document that this use case is no longer possible in 5.x.

We've already documented that the response body is not readable on these special response objects.

We’re going from ‘you can't read it because it’s null’ to ‘you can’t read it even though it’s not null’, which is certainly more annoying in generic use cases. But unsupported operations is not new and rarely problematic; like forbidding add() on a Collections.emptyList()

Except that network responses did not use to return null

Hmm, it seems you are 100% correct and they did return null. I swear I saw them at some point but I could be wrong.

So close?

Yes, thanks for helping me out here, I have some new ideas on how to improve the inspector