http请求响应头缺失Content-Length头信息的问题

对接第三方对象存储的服务最近总是有warning日志，远程上传的对象get请求返回的响应头中缺失content-length信息
go程序中获取到的content-length值为-1

之前被content-length值为-1坑过，具体场景为程序中使用 minio 作为sdk对接第三方对象存储
使用PutObject方法完成远程上传，即通过http get获取源对象，直接上传，不进行本地转存，原本运行挺稳定，直到出现大量响应头信息缺失content-length的资源出现
当时使用的minio版本为github.com/minio/minio-go v6.0.8+incompatible，此版本中当不显式传入大于0的size（对应http请求返回的content-length）时，将采用分块上传的逻辑
但是每块的体积是500M，计算方式是最大对象体积/最大分块数
最开始是串行上传，所以并没有暴露问题，直到为了优化性能利用带宽，改成了并行上传时，OOM了，因为需要同时上传的对象数n*500M的内存，这啥配置顶得住
这个问题的解决方案是升级了minio版本到v7，可以配置默认的chunk大小，不再是500M，然后将有问题的源都改为支持返回content-length，同时对获取不到content-length的请求添加告警，包括chunked
所以再看到这个告警还是要重视的
结果大跌眼镜，是个内部服务提供的远程上传链接，有着不少诡异的清空，初期很是抓头

前提

Content-Length

Content-Length 表示请求/响应实体内容的长度（字节）
一般是自动生成的，并不需要手动指定修改，手动操作反而会引发错误，比如在chrome浏览器中发送ajax时进行操作，可以试试

当内容的实际字节数大于 Content-Length 时
- 当服务端接收的请求实体长度超过 Content-Length ，服务端会直接关闭连接，从而导致请求失败
- 当服务端返回的响应实体长度超过 Content-Length，超出 Content-Length 长度的内容将被丢弃
当内容的实际字节数小于 Content-Length 时
- 当服务端接收的请求实体长度小于 Content-Length，服务端会继续等待后面的数据，从而导致超时
- 当服务端返回的响应实体长度小于 Content-Length，浏览器会报错，如Chrome 浏览器会报 net::ERR_CONTENT_LENGTH_MISMATCH

可见Content-Length适用于消息体长度明确的情况，Content-Length 无法提前计算出来的情况则使用分段传输

Transfer-Encoding

分块传输编码（Chunked transfer encoding）是超文本传输协议（HTTP）中的一种数据传输机制，允许HTTP由网页服务器发送给客户端应用（通常是网页浏览器）的数据可以分成多个部分。分块传输编码只在HTTP协议1.1版本（HTTP/1.1）中提供
Transfer-Encoding 和 Content-Length 是互斥的，如果同时出现，浏览器以 Transfer-Encoding 为准，在Go中，会从header中删除两个信息，然后设置TransferEncoding和ContentLength属性
具体可以参考net/http源码

// srs/net/http/transfer.go
// parseTransferEncoding sets t.Chunked based on the Transfer-Encoding header.
func (t *transferReader) parseTransferEncoding() error {
	raw, present := t.Header["Transfer-Encoding"]
	if !present {
		return nil
	}
	delete(t.Header, "Transfer-Encoding")

	// Issue 12785; ignore Transfer-Encoding on HTTP/1.0 requests.
	if !t.protoAtLeast(1, 1) {
		return nil
	}

	// Like nginx, we only support a single Transfer-Encoding header field, and
	// only if set to "chunked". This is one of the most security sensitive
	// surfaces in HTTP/1.1 due to the risk of request smuggling, so we keep it
	// strict and simple.
	if len(raw) != 1 {
		return &unsupportedTEError{fmt.Sprintf("too many transfer encodings: %q", raw)}
	}
	if !ascii.EqualFold(textproto.TrimString(raw[0]), "chunked") {
		return &unsupportedTEError{fmt.Sprintf("unsupported transfer encoding: %q", raw[0])}
	}

	// RFC 7230 3.3.2 says "A sender MUST NOT send a Content-Length header field
	// in any message that contains a Transfer-Encoding header field."
	//
	// but also: "If a message is received with both a Transfer-Encoding and a
	// Content-Length header field, the Transfer-Encoding overrides the
	// Content-Length. Such a message might indicate an attempt to perform
	// request smuggling (Section 9.5) or response splitting (Section 9.4) and
	// ought to be handled as an error. A sender MUST remove the received
	// Content-Length field prior to forwarding such a message downstream."
	//
	// Reportedly, these appear in the wild.
	delete(t.Header, "Content-Length")

	t.Chunked = true
	return nil
}

...
    // Unify output
    switch rr := msg.(type) {
    case *Request:
        rr.Body = t.Body
        rr.ContentLength = t.ContentLength
        if t.Chunked {
            rr.TransferEncoding = []string{"chunked"}
        }
        rr.Close = t.Close
        rr.Trailer = t.Trailer
    case *Response:
        rr.Body = t.Body
        rr.ContentLength = t.ContentLength
        if t.Chunked {
            rr.TransferEncoding = []string{"chunked"}
        }
        rr.Close = t.Close
        rr.Trailer = t.Trailer
    }

问题

不是100%出现
同样的接口，Go请求不返回content-length，但curl访问则返回
同样的代码，其它服务中的文件访问均会返回content-length

原因

1. 并不是每个请求都能复现

通过观察日志，正常返回content-length的请求，其content-length值均不大于255
通过创建特殊文件请求验证，确认只有大于等于256字节的文件被访问时才会出现不返回content-length的情况

1. curl表现不一致的问题

通过排查，定位到 compressed 这个配置上，如果显示的添加配置 curl --compressed，则表现与Go请求一致，即获取到了chunked 响应
而compressed是指定请求要压缩的，对接收到的响应也会自动进行解压缩。即默认请求是不进行压缩的，所以会返回content-length头
同理，如果Go请求时指定 Accept-Encoding 为 identity，可以达到同样的效果

2. 同代码不同表现的原因

由于有参照，通过控制变量发的对比发现唯一的不同是其他服务是内网访问，而出问题的服务配置了公网地址访问
那么问题就只能是出在了多余的公网访问这一步。而服务是k8s集群内的，那么就是使用的ingress-nginx配置上有文章了
先找到ingress的pod，然后查看pod的nginx配置

$ kubectl get po -n ingress-nginx
NAME                                   READY   STATUS    RESTARTS   AGE
default-http-backend-7c6b4d97f-xx6qx   1/1     Running   36         1y
nginx-ingress-controller-48h52         1/1     Running   1          178d
nginx-ingress-controller-7nwrq         1/1     Running   0          178d
nginx-ingress-controller-fbf8c         1/1     Running   1          178d
nginx-ingress-controller-gtbg2         1/1     Running   1          178d
nginx-ingress-controller-hz8l7         1/1     Running   1          178d
nginx-ingress-controller-kxh2b         1/1     Running   1          178d

# 随便一个pod
$ kubectl exec -it nginx-ingress-controller-48h52 -n ingress-nginx -- cat /etc/nginx/nginx.conf > nginx.conf
# 搜索nginx.conf文件

果然，发现了这些配置

gzip on;
gzip_comp_level 5;
gzip_http_version 1.1;
gzip_min_length 256;
gzip_types application/atom+xml application/javascript application/x-javascript application/json application/rss+xml application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/svg+xml image/x-icon text/css text/plain text/x-component;
gzip_proxied any;
gzip_vary on;

其中gzip_min_length 256;对应了问题1，响应达到256字节的请求才会出现状况的原因
而nginx中chunked_transfer_encoding又是默认开启（on）的，所以导致文件被压缩后通过分块传输的方式对外响应，从而表现出content-length响应头信息丢失的现象

为什么gzip会导致分块传输 Transfer-Encoding: chunked ?

虽然原始的服务提供者的http响应是未分块且响应了正确的头信息 Content-Length 的
由于请求经过了ingress-nginx（或者其它形式的），根据其配置，超过 gzip_min_length 大小的响应body需要被压缩
header 是先于 body 被发送的，但应用 gzip 压缩的过程会导致 body 的体积变化，且压缩完成前是不知道其明确的体积的，所以此场景下只能选择分块传输
这都是因为nginx的gzip默认是动态压缩的，如果又要压缩，又要返回content-length，则需要额外的 gzip_static 模块 ngx_http_gzip_static_module 支持，添加模块后加入配置 gzip_static on; 即可实现

gzip_static 开启需要额外的存储空间，自行权衡

解决方法

指定不压缩
有一定的风险，毕竟不压缩会造成带宽的额外开销，如果确定影响不大，那么就可以放心设置
1
2
req, err := http.NewRequest("GET", url, nil)
req.Header.Set("Accept-Encoding", "identity")
绕过nginx
已经分析到原始的服务返回是没有分块传输的，是ingress造成的这个现象，而又有直接内网访问的方案来解决，所以绕过它就好了

参考链接

原文链接
 分块传输编码
 ngx_http_gzip_static_module