chucker
chucker copied to clipboard
ChuckerTeam
Share action and save file have different outputs
:writing_hand: Describe the bug
When sharing in Chucker or saving a file in chucker, the outputs are different. Most importantly the save as file does not include all of the information about the request/response (like headers)
:wrench: Expected behavior
It would be awesome to have save file have the same output as share action
When sharing in Chucker or saving a file in chucker, the outputs are different. Most importantly the save as file does not include all of the information about the request/response (like headers)
The current "Save body to file" action is actually (as the name suggests) saving only the body. This allows to save images and actually view them outside of chucker.
The share text instead is sharing a "readable" representation of the HTTP call. This means that binary payloads will be omitted.
I'll argue that they're both useful and they should not be changed as of today. On the other hand we should probably offer to save in different formats (e.g. text, binary, .har files, etc.)
This is also related to: #401
@cortinico I guess the main workflow I'm trying to resolve is that I want to give my backend team full request/response of a bad network call. Sharing into slack doesn't work because the amount of text is too large... and so now I don't really know what the best way to take a full request/response and send it to my team is. I thought the save as file would be best for that so that the "share"/"save" actions always have the same output.
Once something like #401 is complete, you can export one transaction, or all of them, and share with your backend team via something like slack, and they can import it into the tool of their choice (Charles Proxy, Chrome Debug Tools, etc). From there, they can view the entire request/response.
This could be attached as a JSON file with a .har extension.
I would still say that a simple text based export has a lot of value. Typically the iOS/android/web team all just show their request/response right in line in slack. It makes it really easy. I'm not saying that .har isn't valuable, but ease of sharing is key.
For sure. I'm guessing your team is potentially different than mine. At my company, we have QA teams working at different companies, without direct lines of communication to developers, and bugs typically arise from complex network interactions that are hard to view via simple request/response. I think both export types provide value.