--Response:Body argument writes response to file as string, regardless of content type

[tlmii]

Currently, for any HTTP command (GET, POST, PUT, etc) you can specify to have the responses saved to a file on disk. There are three arguments that control this:

1. --response:Headers {fileName} writes just the response headers to a file on disk
2. --response:Body {fileName} writes just the response body to a file on disk
3. --response {fileName} writes both the response headers AND response body to a file on disk

All of this works right now if the response you're expecting is text-based (plain text, xml, json, etc). But if the response you're expecting for a particular API call is anything else (say, an image file, or any other file you're requesting through a storage API) then 1 works as expected, but 2 and 3 do not because the response body is just treated as a string.

It seems reasonable to me that when doing 2, we should always write out the response bytes, not a string variant of it. That'll still give the expected results for a text-based response, but handle the other scenarios as well.

Its not as clear to me what we should do with 3, however. First thought would be that it'd be nice to write the raw response to disk in that case. But it doesn't look like HttpClient makes it easy to get the full raw response (you'd have to piece it back together from headers, content, etc). I suppose it could be as simple as writing the headers as text, then appending the content as bytes. Just not sure what purpose that would serve for the non-text responses. But perhaps that is enough of an edge case (users who want to write headers AND body of responses that are NOT text) as to not be a concern right now?

@bradygaster this is the bug I was talking to you about today.

[tlmii]

I suppose another option here would be to just drop the --response {fileName} option altogether. This is a new major version, so we can make that break. Unfortunately we don't have any info on how often it is used. I think these will all be changed when we do the command syntax and usability review anyway.

[bradygaster]

--response {fileName} writes both the response headers AND response body to a file on disk

what's the delineator/separator?

[bradygaster]

let's table non-text for the time being. we'll circle back to that after the push and just focus in this round. Given that, how would you modify the description?

[tlmii]

@bradygaster

what's the delineator/separator?

Well, it turns out it doesn't even work right now (and hasn't since the 3.0 previews). The body contents overwrite the header contents.

I suppose another option here would be to just drop the --response {fileName} option altogether.

The above discovery adds some weight to this idea - because that option has never worked and no one has complained.

[bradygaster]

I move we close this. If customers start doing things with binary data and it becomes an important issue, we'll re-open. For now I just don't feel like it's a wide-enough case for us to spend cycles on it.