Add action to save response body to file

[LucasPickering]

Description

Describe the change. If there is an associated issue, please include the issue link (e.g. "Closes #xxx"). For UI changes, please also include screenshots.

Closes #183

Adds a new action "Save Body as File" to the response pane. The content to be saved has three possible values:

• If the content is a known type (right now just JSON), we'll save exactly what's seen. That means the prettified version of the body, potentially with a query applied.
• If the content is an unknown text type, save the raw content (again, exactly what's seen)
• If the content is binary (e.g. an image), save the raw bytes rather than what's seen (which is a hex representation of the bytes)

Once the content to be saved is determined, it will prompt the user for a file name to save as. We'll try to figure out a default file name according to these steps:

• Check the Content-Disposition header for a filename="<value>" parameter. If present, use <value>
• Check the Content-Type header to get the extension from the content subtype (e.g. json from application/json, or png from image/png). The file name will be data.<extension>
• If Content-Type header is missing or invalid (extremely uncommon), provide no default

Once we have a file name, we can join it with the current working directory to get a path. Then we try to save to that file. If the file already exists, we'll prompt the user with a yes/no confirmation to make sure they want to overwrite it.

Known Risks

What issues could potentially go wrong with this change? Is it a breaking change? What have you done to mitigate any potential risks?

The behavior described above is a bit complex, which introduces room both for bugs and surprising behaviors. For example, users might be surprised that if they have JSON query applied, it will save the query result rather than the full file. I think it's fairly intuitive to save what you see, and that's also how the "Copy Body" action works so it's consistent at least. I wouldn't be surprised if we get some issues filed about this in the future. To mitigate the bug issue, I'll be adding tests.

There's potential risk around the handling of file paths, e.g. path traversal. I didn't do any handling here, instead leaning on the OS/file system to protect itself. Since this is a client-side app, we don't have to worry about people overwriting system files etc. that they don't have access to. It's possible a user could accidentally overwrite an existing file, which is mitigated with the "This file already exists" confirmation.

QA

How did you test this?

Just manually tested for now. I really want to add unit tests but we don't have any established for the UI yet, so I need to figure out some patterns for that. Working on it now.

Checklist

• Have you read CONTRIBUTING.md already?
• Did you update CHANGELOG.md?
  • Only user-facing changes belong in the changelog. Internal changes such as refactors should only be included if they'll impact users, e.g. via performance improvement.
• Did you remove all TODOs?
  • If there are unresolved issues, please open a follow-on issue and link to it in a comment so future work can be tracked

[LucasPickering]

@kristopherbullinger This is working, but needs tests before I merge it. If you want to test it out, you can install this branch with:

cargo install --git https://github.com/LucasPickering/slumber --branch save-body

If you're able to try it, let me know if you run into any issues. Thanks!

[kristopherbullinger]

Some brief testing confirms that it works as expected for html, png, and plain text. When the response content-type=text/plain, the suggested extension is .plain, but I think the best file extension would be .txt. It's easy enough to override for now. Encoding smart detection of proper extensions would require a lot of small rules which can be added over time.

LGTM and Thank You