Fiddler环绕JSON响应

huangapple go评论88阅读模式
英文:

Fiddler Surrounds JSON Response

问题

我有一个用Go实现的Web服务,它从外部服务返回一个JSON结构。返回的对象看起来像这样:

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

我的Go Web服务只是将JSON读取到一个切片中:

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

然后将其返回给客户端:

w.Write(response)

在Postman中,响应显示为原样,但是Fiddler在响应之前和之后都添加了以下内容:

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

请注意前面的34ee和后面的0

然后我被提示转换响应:

"响应已编码,可能需要解码才能进行检查。"

接受提示后,会返回原始的JSON。是Go的w.Write方法添加了额外的字符,还是这是特定于Fiddler的?

顺便说一下,在写入缓冲区之前,我设置了以下标头:

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

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")

答案1

得分: 3

这是一个HTTP 1.1分块响应。协议将以以下格式发送:

十六进制的块大小
块数据
...

最后一个大小为0的块表示响应结束。你的示例显示响应大小为13550字节,并且以一个块发送。

英文:

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.

答案2

得分: 1

您正在处理一个分块响应。我不确定您的最终目标是什么,但有几个不同的选项。源代码本身说:

// Body表示响应体。
//
// http客户端和传输保证Body始终为非nil,即使是没有响应体或者长度为零的响应。关闭Body是调用者的责任。
//
// 如果服务器使用“chunked”传输编码,Body会自动解除分块。
Body io.ReadCloser

所以例如在这里:response, err := ioutil.ReadAll(resp.Body),您正在传递来自其他服务的响应,您可以通过让提供resp的服务设置一个带有值为chunked的Transfer-Encoding头来解决问题,假设您也可以访问该API。如果您只在这个中间层工作,那么您将不得不在写入之前自己解除分块响应。如果您在Fiddler中监视的请求没有chunked传输编码,只需添加该编码可能会导致Fiddler以与Postman中看到的相同方式显示它。

英文:

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.

huangapple
  • 本文由 发表于 2015年8月8日 00:11:07
  • 转载请务必保留本文链接:https://go.coder-hub.com/31882254.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定