看来wget之前也存在此类问题，于是继续搜索标准，输出如下：
深入源码The presence of a message body in a response depends on both the request method to which it is responding and the response status code (Section 3.1.2). Responses to the HEAD request method (Section 4.3.2 of [RFC7231]) never include a message body because the associated response header fields (e.g., Transfer-Encoding, Content-Length, etc.), if present, indicate only what their values would have been if the request method had been GET (Section 4.3.1 of [RFC7231]). 2xx (Successful) responses to a CONNECT request method (Section 4.3.6 of [RFC7231]) switch to tunnel mode instead of having a message body. All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses do not include a message body. All other responses do include a message body, although the body might be of zero length.
从上节标准可以看出，在http 204、304的时候，不允许返回Content-Length，那么如果返回了，libcurl又是如何处理的呢？
于是在curl的issue上进行了关键字搜索，得到了如下结果：
看来已经有人提过这个问题了，于是看了下当前线上libcurl的源码：
switch(k->httpcode) {
case 204:
/* (quote from RFC2616, section 10.2.5): The server has
* fulfilled the request but does not need to return an
* entity-body ... The 204 response MUST NOT include a
* message-body, and thus is always terminated by the first
* empty line after the header fields. */
/* FALLTHROUGH */
case 304:
/* (quote from RFC2616, section 10.3.5): The 304 response
* MUST NOT contain a message-body, and thus is always
* terminated by the first empty line after the header
* fields. */
if(data->set.timecondition)
data->info.timecond = TRUE;
k->size=0;
k->maxdownload=0;
k->ignorecl = TRUE; /* ignore Content-Length headers */
break;
线上使用的版本果然没有处理此种情况，再跟线上做对比，改动如下：
好了，问题已经解决，原因也已经找到，毕竟不是大bug，为了稳妥起见，还是不升级了，以稳定为主，谁知道升级后又会出现什么意想不到的问题呢
结语该问题从发现到解决，大概用了2天的时间。其实，从文章的目录结构就能发现，整个问题发现以及解决过程跟文章目录结构一致:收到报警->双方沟通->业务代码->线上抓包->同类对比->问题解决->原因分析->深入源码。
原文链接：https://mp.weixin.qq.com/s/EoUZ_T-pK_MRmRaOIfHgsQ
