Fiddler Surrounds JSON Response

Question

I have a web service implemented in Go that returns a JSON structure from an external service. Upon returning the object, it looks like this:

{"otherServiceInfoList":[],"action...

My Go web service simply reads the JSON to a slice:

response, err := ioutil.ReadAll(resp.Body)

and returns it to the client:

w.Write(response)

The response is displayed as-is in Postman, however Fiddler both prepends and appends the response as follows:

34ee
{"otherServiceInfoList":[],"...
0

Note the leading 34ee and trailing 0.

I am then promoted to transform the response:

"Response is encoded and may require decoding before inspection."

Accepting the prompt removes returns the original JSON. Is Go's w.write method applying the extra characters, or is this specific to Fiddler?

Incidentally, I'm setting the following header before writing to the buffer:

w.Header().Set("Content-Type", "application/json; charset=UTF-8")

Answer 1

This is http 1.1 chunked response. The protocol will send the format:

size-of-chunk-in-hex
chunk
...

The final chunk size of 0 signifies the end of the response. Your example show the response is 13550 bytes, and is sent in one chunk.

Answer 2

You're dealing with a chunked response. I'm not sure what your end goal is but there are a few different options. The source itself says;

    // Body represents the response body.
    //
    // The http Client and Transport guarantee that Body is always
    // non-nil, even on responses without a body or responses with
    // a zero-length body. It is the caller's responsibility to
    // close Body.
    //
    // The Body is automatically dechunked if the server replied
    // with a "chunked" Transfer-Encoding.
    Body io.ReadCloser

So for example here; response, err := ioutil.ReadAll(resp.Body) where you're relaying the response from the other service, you could fix the problem by making the service that provided resp set a Transfer-Encoding header with the value chunked, assuming you have access to that api as well. If you're only working in this middle layer, then you'll have to dechunk the response yourself before writing it. If the request you're monitoring in Fiddler doesn't have chunked Transfer-Encoding, just adding that may cause Fiddler to display it the same as you see it in Postman.