Go 检测gzip编码以手动解压缩响应，但'；内容编码'；标题缺失

我正在使用'Go'中的

net/http

库发出

httpget

请求。在回复中，我得到了12个标题。但是当我通过postman运行完全相同的查询时，我得到了16个标题。其中缺少的是“内容编码”。我知道这一定是个问题

但是，由于我没有在请求中设置头

Accept Encoding:gzip

，并且我仍然得到gzip编码的响应，因此Go传输没有。因此，我需要能够手动检测编码，然后解压缩它。但是，我无法检测响应中是否缺少“Content Encoding”头

以下是我尝试执行此操作的代码：

func calcDistanceAndDurationWithUberApi(originLat float64, originLon float64, destinationLat float64, destinationLon float64) (float64, float64, error) {

    endpoint := "https://api.uber.com/v1.2/estimates/price"
    parameters := fmt.Sprintf("?start_latitude=%v&start_longitude=%v&end_latitude=%v&end_longitude=%v", originLat, originLon, destinationLat, destinationLon)

    req, err := http.NewRequest("GET", endpoint + parameters, nil)
    if err != nil {
        return 0, 0, err
    }

    req.Header.Add("Authorization", "Token " + getUberApiKey())
    req.Header.Add("Accept-Language", "en_US")
    req.Header.Add("Content-Type", "application/json")

    httpClient := &http.Client{}
    resp, err := httpClient.Do(req)
    if err != nil {
        return 0, 0, err
    }
    if resp.StatusCode != 200 {
        return 0, 0, errors.NotFound("Response: %v", resp.StatusCode)
    }
    defer resp.Body.Close()

    pretty.Println("- REQUEST: ")
    pretty.Println(req)

    // Check if server sent gzipped response. Decompress if yes.
    var respReader io.ReadCloser
    switch resp.Header.Get("Content-Encoding") {
    case "gzip":
        fmt.Println("Content-Encoding is gzip")
        respReader, err = gzip.NewReader(resp.Body)
        defer respReader.Close()
    default:
        fmt.Println("Content-Encoding is Not gzip")
        respReader = resp.Body
    }

    pretty.Println("- RESPONSE HEADER: ")
    pretty.Println(resp.Header)

    pretty.Println("- RESPONSE BODY: ")
    pretty.Println(respReader)

    return 0, 0, nil
}

响应状态为“200正常”。以下是输出（响应）：

---

我屈服于uber api的顽固性，添加了另一个请求头，

req.header.Add（“接受编码”，“gzip”）

---

现在我得到了响应头

“Content Encoding”：“gzip”

，虽然我仍然得到了一个无法理解的响应体，但这超出了这个问题的范围。

我屈服于优步api的顽固性，添加了另一个请求头

req.header.Add（“接受编码”，“gzip”）

---

现在我得到了响应头

“Content Encoding”：“gzip”

，虽然我仍然得到了一个无法理解的响应体，但这超出了这个问题的范围。

Uber的API可能足够聪明，只有在请求者接受gzip时才包含内容编码头，但实际上还不够聪明，当他们不接受gzip时，他们不会拒绝gzip响应。如果是这样的话，这肯定是Uber端的一个缺陷。但同时，无论我是否问他们Uber的API是否足够聪明，如果请求者接受gzip，他们都会固执地给我gzip ped响应，但实际上还不够聪明，当他们不接受gzip时，他们不会拒绝gzip响应。如果是这样的话，这肯定是优步终端的一个缺陷。但同时，无论我是否要求他们这样做，他们都固执地给了我一个答复

- RESPONSE HEADER: 
http.Header{
    "Content-Language":          {"en"},
    "Cache-Control":             {"max-age=0"},
    "X-Uber-App":                {"uberex-nonsandbox", "optimus"},
    "Strict-Transport-Security": {"max-age=604800", "max-age=2592000"},
    "X-Content-Type-Options":    {"nosniff"},
    "Date":                      {"Fri, 19 May 2017 07:52:17 GMT"},
    "Content-Geo-System":        {"wgs-84"},
    "Connection":                {"keep-alive"},
    "X-Frame-Options":           {"SAMEORIGIN"},
    "X-Xss-Protection":          {"1; mode=block"},
    "Server":                    {"nginx"},
    "Content-Type":              {"application/json"},
}
- RESPONSE BODY: 
&http.gzipReader{
body: &http.bodyEOFSignal{
    body: &http.body{
        src: &internal.chunkedReader{
            r:  &bufio.Reader{
                buf: {0x48, 0x54, .......... }