Closed denislutz closed 1 year ago
Hi @denislutz, talkback will store the request body unencoded (human readable) if both the content-type and content-encoding are supported. Most common encodings are supported.
What seems to be happening here is that your request is missing the content-type header. Without it, talkback has no way of understanding what is being sent in the request so it fallbacks to treating the request body as binary content.
Since it seems you are calling a graphql endpoint, you could send the "application/json" content type. Note that Talkback currently doesn't list "application/graphql" as a human-readable content-type, but I will add it for a future release.
Thank you so much, I can recommend mentioning this in the doc, close to the attribute about human readable, I had this situation many time and didn't really knew the reasons behind it.
Makes sense, I added a note about it under the Tapes section.
Hi Guys,
I would appreciate to know whats the logic behind encoded body parts of the request? What I usually get as a recorded tape something like this;
I hope you agree that any test setup rather likes it to be readable and understandable and it is the usual case that you use talkbak in development. For that reason it would be nice to know whats the philosophy behind encoding and how I can disable that.
I tried to understand the logic inside the talkback, but I am sure at least the author can say in one shot what is the reasonable way to approach that. Here is what I found in the talkback source
The docu is not really mentioning it either.
Thanks a lot in advance, and many thanks for creating talkback its a rocket for me in any project.
Regards...