transfer-encoding和content-length的不同实现

发布网友 发布时间：2022-04-21 12:17

我来回答

共2个回答

热心网友 时间：2022-04-21 13:47

前段时间在项目中看到如下的代码：

HttpServletResponse response = (HttpServletResponse)servletResponse;
   response.setHeader("Transfer-Encoding", "utf8");
   filterChain.doFilter(servletRequest, servletResponse);

原意是想对输出的内容进行编码，却用错了响应头，结果这个错误的响应头对后面的客户端程序带来了许多麻烦。这里有必要对这个这块的内容进行详细地了解。

传输数据编码：Transfer-Encoding 
数据编码，即表示数据在网络传输当中，使用怎么样的保证方式来保证数据是安全成功地传输处理。可以是分段传输，也可以是不分段，直接使用原数据进行传输。 
有效的值为：Trunked和Identity. 
传输内容编码：Content-Encoding 
内容编码，即整个数据信息是在数据器端经过怎样的编码处理，然后客户端会以怎么的编码来反向处理，以得到原始的内容。这里的内容编码主要是指压缩编码，即服务器端压缩，客户端解压缩。 
可以参考的值为：gzip,compress,deflate和identity。 
传输内容格式：Content-Type 
内容格式，即接收的数据最终是以何种的形式显示在浏览器中。可以是一个图片，还是一段文本，或者是一段html。内容格式额外支持可选参数,charset，即实际内容的字符集。通过字符集，客户端可以对数据进行解编码，以最终显示可以看得懂的文字（而不是一段byte[]或者是乱码)。

3种描述信息，可以由下图来表示(来源于《Http权威指南》)：

从上文中，可以看出，实际上原filter中的内容可能是想表达以下的意思:

response.setContentType("text/html;charset=UTF8");
//或者
response.setContentType("application/json;charset=UTF8");

内容长度：Content-Length 
内容长度，即表示整个传输内容的有效长度信息。客户端可以通过此头信息来判断接收的数据是否已经完全接收。此编码和transfer-encoding相冲突，因为transfer-encoding会通过额外的处理方式来改变数据的组织方式，就会改变实际的数据长度，如果客户端仍按照原content-length来处理的话，则不会接收到完整的数据。

由于transfer-encoding和content-length之间存在冲突问题，因此在服务端和客户端就会有相应的实现来支持相应的数据处理。整个处理过程按照RFC 2616来处理。

处理规则：(http://tools.ietf.org/html/rfc2616#page-119所述)

If a Content-Length header field (section 14.13) is present, its
 decimal value in OCTETs represents both the entity-length and the
 transfer-length. The Content-Length header field MUST NOT be sent
 if these two lengths are different (i.e., if a Transfer-Encoding
 header field is present). If a message is received with both a
 Transfer-Encoding header field and a Content-Length header field,
 the latter MUST be ignored.

即通常使用content-length来表示内容长度。但如果存在transfer-encodig时，就不能再使用content-length了，而且也不应该再出现content-length头。既使服务器端同时有2个头信息，content-length也应该被忽略。

服务器端实现Tomcat

tomcat在实现transfer-encoding时默认采用trunked传输，但如果应用指定追加了content-length，则会使用content-length的值，就不再追加transfer-encoding了。相应的实现在类AbstractHttp11Processor方法prepareResponse中(tomcat7.0.52版本):

//先判断是否存在，contentLength头，即应用调用setContentLength方法，如果调用了。这里获取的值肯定不为-1
long contentLength = response.getContentLengthLong();
   boolean connectionClosePresent = false;
   if (contentLength != -1) {
     headers.setValue("Content-Length").setLong(contentLength);
//因为使用了content-length，所以在数据传输时，就不再进行额外处理了，直接将原数据输出至客户端即可。
     getOutputBuffer().addActiveFilter
       (outputFilters[Constants.IDENTITY_FILTER]);
     contentDelimitation = true;
   } else {
     // If the response code supports an entity body and we're on
     // HTTP 1.1 then we chunk unless we have a Connection: close header
     connectionClosePresent = isConnectionClose(headers);
//这里即默认使用trunked，但需要有相应的前提
//如果客户端显示设置Connetion:close时，即表示客户端只会请求一次，不会使用Keep-Alive，这样的话，不需要使用trunked传输，
//因为客户端知道何时数据已经传输完，使用read() == -1即可判断
     if (entityBody && http11 && !connectionClosePresent) {
//使用ChunkedOutputFilter来对传输的数据二次处理，即分段传输
       getOutputBuffer().addActiveFilter
         (outputFilters[Constants.CHUNKED_FILTER]);
       contentDelimitation = true;
       headers.addValue(Constants.TRANSFERENCODING).setString(Constants.CHUNKED);
     } else {
//最后使用原始数据传输方式
       getOutputBuffer().addActiveFilter
         (outputFilters[Constants.IDENTITY_FILTER]);
     }
   }

此段代码将在应用处理完逻辑或者调用response.outputStream.write时会调用。详细的处理逻辑，可参考上文中的注释。

需要注意的是，由于Http工作在TCP/IP之上，因此数据的完整性保证已经不需要由Http来处理了。所以依靠trunked来保证数据完整性已经没有太大意义。现在trunked的意义在于针对keep alive传输时，trunked可以通过特殊的处理来告诉客户端(通过发送头长度0来标识)，该次的数据已经响应完毕。客户端可以处理并再次使用该连接进行下一次处理了。所以在上面的trunked处理中，tomcat如果认为没有使用trunked的必要时，就不会强制使用trunked了(如connection:close这种一次性请求模型)

客户端实现HttpClient

httpclient(版本4.3.3）的主要实现在类EntityDeserializer中，即如何去获取数据并反向解码。实现方法为doDeserialize，主要的实现如下所示：

final long len = this.lenStrategy.determineLength(message);
   if (len == ContentLengthStrategy.CHUNKED) {
     entity.setChunked(true);
     entity.setContentLength(-1);
     entity.setContent(new ChunkedInputStream(inbuffer));
   } else if (len == ContentLengthStrategy.IDENTITY) {
     entity.setChunked(false);
     entity.setContentLength(-1);
     entity.setContent(new IdentityInputStream(inbuffer));
   } else {
     entity.setChunked(false);
     entity.setContentLength(len);
     entity.setContent(new ContentLengthInputStream(inbuffer, len));
   }

即通过判断lengh值来确定是使用不同的数据解析。解析出来的流处理共有3种不同的处理方式，即transfer-encoding中指定的chunked和identity，以及由content-length指定的处理方式。 
对length的判断逻辑如下所示:

final Header transferEncodingHeader = message.getFirstHeader(HTTP.TRANSFER_ENCODING);
   // We use Transfer-Encoding if present and ignore Content-Length.
   // RFC2616, 4.4 item number 3
//首先根据RFC26216 4.4中介绍的，首先处理transfer-encoding
   if (transferEncodingHeader != null) {
     final HeaderElement[] encodings;
       encodings = transferEncodingHeader.getElements();
     // The chunked encoding must be the last one applied RFC2616, 14.41
     final int len = encodings.length;
//只判断是否和trunked和identity相等，在都不相等的情况下默认使用identity，以避免解析出错的情况
     if (HTTP.IDENTITY_CODING.equalsIgnoreCase(transferEncodingHeader.getValue())) {
       return IDENTITY;
     } else if ((len > 0) && (HTTP.CHUNK_CODING.equalsIgnoreCase(
         encodings[len - 1].getName()))) {
       return CHUNKED;
     } else {
       return IDENTITY;
     }
   }
//然后再使用content-length，这里同样判断，只有在确定好conten-length的情况下才使用，如果确定不好，仍然使用identity
   final Header contentLengthHeader = message.getFirstHeader(HTTP.CONTENT_LEN);
   if (contentLengthHeader != null) {
     long contentlen = -1;
     final Header[] headers = message.getHeaders(HTTP.CONTENT_LEN);
         contentlen = Long.parseLong(header.getValue());
     }
     if (contentlen >= 0) {
       return contentlen;
     } else {
       return IDENTITY;
     }
   }

在以上的处理当中，我们看到identity处理方式最多的。可以理解为，只要是不能解析的都使用identity，即原始处理方式。 
通过以上的实现，可以了解客户端在接收完数据之后的不同响应方式和处理逻辑，这也能解释在项目中的奇怪情况了。

问题出现及解决

在我们的项目中，由于上面的错误的filter的问题。我们在之前使用httpclient在接收数据时(使用httpPost)，本来想接收一个json数据串，即总是返回类似以下的数据:

20
{abxxx.......}
0

这种情况只在处理我们请求的服务才会出现，请求其它之前的项目服务不会出现。多次发现这个特殊的值，好像表示数据长度。在不知道原因的情况下，我们通过在服务中加入以下代码之后，问题好像就解决了：

byte[] bytes = generatedBytes();//生成json bytes数组信息
response.setContentLength(bytes.length);//强制性设置contentLength值
response.getoutputStream.write(bytes);

但又有一个问题发生了，发现响应很慢。每次请求都要花费接近20s的时间，但监控服务代码，响应很快的。而且在服务返回之后，客户端需要继续等待一段时间才返回数据。经debug代码，最终发现httpclient在使用EntityUtils.toString中是这样写的:

final Reader reader = new InputStreamReader(instream, charset);
 final CharArrayBuffer buffer = new CharArrayBuffer(i);
 final char[] tmp = new char[1024];
 int l;
 while((l = reader.read(tmp)) != -1) {
     buffer.append(tmp, 0, l);
 }
 return buffer.toString();

这里的while循环在连接未关闭的情况下会一直等待。结合到keepAlive属性，这里肯定默认会使用keepAlive进行请求，而后服务器也肯定没有关闭连接。因此，我们又在使用httpClient时，强制加入以下头：

httpPost.addHeader("Connection","Close");

这样声明客户端只会请求一次，就断开连接。加入之后，好像问题再一次解决。

但这种解决方式怎么感觉也不是正规的解决方法，因为只是碰巧处理了这个问题。最终的解决思路，还是在认真了解了Http协议之后，并查看相应的服务代码之后，删除错误的输出头，直接就解决了此问题。至于增加content-length头，这个在删除header之后，可以直接删除了(因为增加了额外的代码)。

热心网友 时间：2022-04-21 15:05