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

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

		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之后,可以直接删除了(因为增加了额外的代码)。

转载请标明出处:i flym
本文地址:https://www.iflym.com/index.php/code/20140601001.html

相关文章:

作者: flym

I am flym,the master of the site:)

发表评论

电子邮件地址不会被公开。 必填项已用*标注