即使响应正常，邮递员仍显示“无法得到任何响应”

Posted 2023-05-07

【中文标题】即使响应正常，邮递员仍显示“无法得到任何响应”

【英文标题】：Postman shows "Could not get any response" even though response is OK

【发布时间】：2019-07-18 01:47:48

【问题描述】：

我有一个 WCF 服务，我向它发出 API 请求。 此 API 调用返回一个 JSON 响应对象，并且在“Accept-Encoding”标头中使用“gzip”值时也能够在 GZIP 压缩中返回它。

问题是当我尝试在 GZIP 中获取响应时，尽管我在 Fiddler 中看到响应和响应的内容正常（200 状态代码）并且可以轻松地在我的C# 客户端。

我查看了 Postman 控制台，但我看到的只是 “错误：标头检查不正确”。 我几乎没有尝试找到有关此标头检查的任何文档，但找不到任何文档。

这些是请求标头：

POST /correction/v1/document?lang=US HTTP/1.1
Content-Type: text/plain
Accept-Encoding: gzip
User-Agent: PostmanRuntime/7.6.0
Accept: */*
content-length: 630
Connection: close

这些是响应标头：

HTTP/1.1 200 OK
Content-Length: 512
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Server: Microsoft-HTTPAPI/2.0
Date: Sun, 24 Feb 2019 14:05:50 GMT
Connection: close

我唯一怀疑是错误的是来自 Fiddler 的这条消息：

我将此代码集成到我的代码中，以便在 WCF 中使用 GZIP。 https://github.com/carlosfigueira/WCFSamples/tree/master/MessageEncoder/GZipEncoderAndAutoFormatSelection

基本上，它在返回客户端之前捕获响应并使用 GZipStream 进行压缩。

【参考方案1】：

我遇到了同样的问题，我添加了以下标题来解决这个问题。

Accept-Encoding : * 

【讨论】：

在我的情况下“*”不起作用 - 我必须明确将其设置为“application/zip”

【参考方案2】：

我能够通过使用标头 Accept-Encoding: */* 来解决类似的问题，或者如果您想具体执行 Accept-Encoding: */* 这样 HTTP 客户端将能够根据接收到的编码类型处理响应，在如果是 gzip，它将解码响应并将其显示为普通文本。

【参考方案3】：

当 REST 服务返回 zip 内容（又名 WinZip 格式）时，我遇到了这个问题。我通过使用 7zip 压缩数据来生成真正的gzip 格式解决了这个错误。

【参考方案4】：

对我来说，我删除了请求标头中的“Accept-Encoding”。