Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Talkback could set a way to enforce req and res as humanReadable at options #56

Closed
skywalkerluc opened this issue Jul 1, 2021 · 5 comments

Comments

@skywalkerluc
Copy link

My case: everytime I run as record-mode, I'm seeing res body as base64. I believe you should be able to enforce req and res as humanReadable at options, instead of changing stuff through decorators for meta data.

@ijpiantanida
Copy link
Owner

Hi @skywalkerluc, is your response payload returning a Content-Type header?

Could you paste one of the created tapes?

@skywalkerluc
Copy link
Author

We're sending 'content-type': 'application/json', here's a close example to how it's been mounted:

{ meta: { createdAt: '2021-06-17T15:47:32.986Z', host: 'out_of_context_host, reqHumanReadable: true, }, req: { url: 'out_of_context_url', method: 'DELETE', headers: { accept: 'application/json', 'content-type': 'application/json', }, body: { out_of_context_data: 'out_of_context_value' }, }, res: { status: 200, headers: { date: [ 'Thu, 17 Jun 2021 15:47:34 GMT', ], 'content-type': [ 'application/json;charset=UTF-8', ], 'content-length': [ '40', ], connection: [ 'keep-alive', ], 'access-control-allow-headers': [ 'origin, x-requested-with, accept', ], 'access-control-allow-methods': [ 'GET, PUT, POST, DELETE,PATCH', ], 'access-control-allow-origin': [ '*', ], 'access-control-max-age': [ '3628800', ], 'cache-control': [ 'no-store', ], 'content-encoding': [ 'gzip', ], expires: [ 'Thu, 17 Jun 2021 16:47:34 GMT', ], pragma: [ 'no-cache', ], 'strict-transport-security': [ 'max-age=out_of_context_value ; includeSubDomains', ], vary: [ 'Accept-Encoding', ], 'x-content-type-options': [ 'nosniff', ], 'x-e-dc': [ 'azeus', ], 'x-frame-options': [ 'DENY', ], 'x-newrelic-app-data': [ 'out_of_context_data', ], 'x-oidc-token-type': [ 'CLIENT_CREDENTIALS', ], 'x-oidc-user-type': [ 'ANONYMOUS', ], 'x-vcap-request-id': [ 'out_of_context_id', ], 'x-xss-protection': [ '1; mode=block', ], }, body: 'base64 going here', }, }

Hoping this to be clear enough, I can provide some other example or how our mock-server is set up.

@ijpiantanida
Copy link
Owner

The server seems to be responding with the right headers that would allow talkback to uncompress and show the body in plain text (content-encoding: gzip and content-type: application/json;charset=UTF-8), so I'm not exactly sure of what's going on yet.

What version of talkback are you using?
Any custom decorators?

@skywalkerluc
Copy link
Author

So, we're using "talkback": "1.11.1", I know it's kinda old. Maybe updating it to the latest could help somehow?
But no, no decorators involved.

@ijpiantanida
Copy link
Owner

Ah, I see! Yes, 1.11.1 didn't have support for compressed responses yet.
v1.12.0 which was the next release added that feature.

Unless you are using node <=10, you should be able to jump to the latest version without major issues.

Keep in mind that tapes that were already stored will not get updated.
You will have to either recreate them or manually edit them, if you understand a little bit of the internals of talkback.
In your case, I think it should be enough to add to meta.

resHumanReadable: true,
resUncompressed: true,

and manually making the base64 body a JSON object (not a string).

This sounds like a good future feature, where talkback automatically improves the stored tapes. But I will need to think a little bit more about it.

I will close the issue, but let me know if you are still having problems making it work.
Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants