Improved handling of encoded/binary bodies

[mattprecious]

💡 Describe the solution you'd like

It would be great if we could optionally provide a custom decoder to handle bodies that aren't plain text. We use protocol buffers, so I would like to be able to print something useful inside Chucker instead of (encoded or binary body omitted).

📊 Describe alternatives you've considered

None

📄 Additional context

An interface with a function that takes the Request/Response and returns a string would probably be enough.

Something like this, but with better naming:

interface BodyDecoder { // Converter?
  fun decodeRequest(request: Request): String?
  fun decodeResponse(response: Response): String?
}

Or maybe you do converter factories like retrofit 🤷

🙋 Do you want to develop this feature yourself?

• Yes
• No

[cortinico]

That's definitely and valuable extension point for Chucker 4.x

[MiSikora]

I was thinking about it for some time as well. The thing I haven't figured out is how we could get correct type for a decoder.

@mattprecious How would getting a concrete adapter look like for this interface? Retrofit relies on concrete types and reflection. We, unfortunately, don't have this information.

Also most likely we wouldn't expose whole Request and Response. Instead it could be some metadata and ByteString that has raw bytes as we use side streaming while the consumer pulls the bytes to their application.

[mattprecious]

Yeah, decoding with proper names and type information wouldn't be straightforward. However, it is possible to decode a proto without that information. My ideas for the steps I would take to incorporate this into our app:

1. Print out the bytes in utf8 hex. This string can be pasted into a tool (like, self-plug: protogram) to decode into something somewhat useful. You don't get class/field/enum names, but it's still very useful information and you can manually map tag/value numbers back to useful names by opening the proto definition yourself if needed.
2. Incorporate protogram into our debug app to save you the step of copying and pasting.
3. If this was being heavily used and could justify the investment, we could use reflection or code-gen something based on our retrofit interface(s) and use the path to know which adapters to use. That's a lot of work, but it sounds plausible.

If we only receive the ByteString then we lose valuable information for decoding like the path, content type, response code, etc.

[MiSikora]

Ok, thanks for the feedback. Will think about it.

And maybe I didn't make myself clear but I wouldn't expose only ByteString. We just can't expose Response and Request because the bodies would be already consumed at the time of processing them. It would have to be some other type that has all available bytes already pulled plus metadata like response codes etc. Unless you didn't mean OkHttp types and was just speaking generally in which case I'm sorry for the confusion. :)

[nienienienie]

@cortinico so was it added as "extension point for Chucker 4.x"?

[cortinico]

Yup this is documented here https://github.com/ChuckerTeam/chucker#decode-body-