HTML是超文本传输协议的缩写。（ ）

超文本传输协议

hypertext transfer protocol（缩写为http）

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。1960年美国人Ted Nelson构思了一种通过计算机处理文本信息的方法，并称之为超文本（hypertext）,这成为了HTTP超文本传输协议标准架构的发展根基。Ted Nelson组织协调万维网协会（World Wide Web Consortium）和互联网工程工作小组（Internet Engineering Task Force ）共同合作研究，最终发布了一系列的RFC，其中著名的RFC 2616定义了HTTP 1.1。

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

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/htmlcharset=UTF8")

//或者

response.setContentType("application/jsoncharset=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")

这样声明客户端只会请求一次，就断开连接。

urllib2是Python的一个获取URLs(Uniform Resource Locators)的组件。他以urlopen函数的形式提供了一个非常简单的接口，下面我们用实例讲解他的使用方法 这是具有利用不同协议获取URLs的能力，他同样提供了一个比较复杂的接口来处理一般情况，例如：基础验证，cookies,代理和其他。 它们通过handlers和openers的对象提供。 urllib2支持获取不同格式的URLs(在URL的":"前定义的字串,例如："ftp"是"ftp:python/rfc2616/') html = response/') 在HTTP请求时，允许你做额外的两件事。首先是你能够发送data表单数据，其次你能够传送额外的关于数据或发送本身的信息("metadata")到服务器，此数据作为HTTP的"headers"来发送。 接下来让我们看看这些如何发送的吧。 Data数据 有时候你希望发送一些数据到URL(通常URL与CGI[通用网关接口]脚本，或其他WEB应用程序挂接)。在HTTP中,这个经常使用熟知的POST请求发送。这个通常在你提交一个HTML表单时由你的浏览器来做。 并不是所有的POSTs都来源于表单，你能够使用POST提交任意的数据到你自己的程序。一般的HTML表单，data需要编码成标准形式。然后做为data参数传到Request对象。编码工作使用urllib的函数而非 urllib2。 代码如下: import urllib import urllib2 url = '' values = {'name' : 'Michael Foord','location' : 'Northampton','language' : 'Python' } data = urllib.urlencode(values) req = urllib2.Request(url, data) response = urllib2.urlopen(req) the_page = response.read() 记住有时需要别的编码(例如从HTML上传文件--看/TR/REC-html40/interact/forms.html#h-17.13 HTML Specification, Form Submission的详细说明)。 如ugoni没有传送data参数，urllib2使用GET方式的请求。GET和POST请求的不同之处是POST请求通常有"副作用"，它们会由于某种途径改变系统状态(例如提交成堆垃圾到你的门口)。 尽管HTTP标准说的很清楚POSTs通常会产生副作用，GET请求不会产生副作用，但没有什么可以阻止GET请求产生副作用，同样POST请求也可能不产生副作用。Data同样可以通过在Get请求 的URL本身上面编码来传送。 可看如下例子 代码如下: >>>import urllib2 >>>import urllib >>>data = {} >>>data['name'] = 'Somebody Here' >>>data['location'] = 'Northampton' >>> data['language'] = 'Python' >>>url_values = urllib.urlencode(data) >>>print url_values name=Somebody+Here&language=Python&location=Northampton >>>url = '' >>>full_url = url + '?' + url_values >>>data = urllib2.open(full_url) Headers 我们将在这里讨论特定的HTTP头，来说明怎样添加headers到你的HTTP请求。 有一些站点不喜欢被程序（非人为访问）访问，或者发送不同版本的内容到不同的浏览器。默认的urllib2把自己作为“Python-urllib/x.y”(x和y是Python主版本和次版本号,例如Python-urllib/2.5)， 这个身份可能会让站点迷惑，或者干脆不工作。浏览器确认自己身份是通过User-Agent头，当你创建了一个请求对象，你可以给他一个包含头数据的字典。下面的例子发送跟上面一样的内容，但把自身 模拟成Internet Explorer。 复制代码 代码如下: import urllib import urllib2 url = '' user_agent = 'Mozilla/4.0 (compatibleMSIE 5.5Windows NT)' values = {'name' : 'Michael Foord','location' : 'Northampton','language' : 'Python' } headers = { 'User-Agent' : user_agent } data = urllib.urlencode(values) req = urllib2.Request(url, data, headers) response = urllib2.urlopen(req) the_page = response.read() response应答对象同样有两个很有用的方法。看下面的节info and geturl，我们将看到当发生错误时会发生什么。 Handle Exceptions处理异常 当urlopen不能够处理一个response时，产生urlError（不过通常的Python APIs异常如ValueError,TypeError等也会同时产生）。 HTTPError是urlError的子类，通常在特定HTTP URLs中产生。 URLError 通常，URLError在没有网络连接(没有路由到特定服务器),或者服务器不存在的情况下产生。这种情况下，异常同样会带有"reason"属性，它是一个tuple，包含了一个错误号和一个错误信息。 例如 复制代码 代码如下: >>>req = urllib2.Request('') >>>try: urllib2.urlopen(req) >>>except URLError, e: >>>print e.reason >>> (4, 'getaddrinfo failed') HTTPError 服务器上每一个HTTP 应答对象response包含一个数字"状态码"。有时状态码指出服务器无法完成请求。默认的处理器会为你处理一部分这种应答(例如:假如response是一个"重定向"，需要客户端从别的地址获取文档 ，urllib2将为你处理)。其他不能处理的，urlopen会产生一个HTTPError。典型的错误包含"404"(页面无法找到)，"403"(请求禁止)，和"401"(带验证请求)。 请看RFC 2616 第十节有所有的HTTP错误码 HTTPError实例产生后会有一个整型'code'属性，是服务器发送的相关错误号。 Error Codes错误码 因为默认的处理器处理了重定向(300以外号码)，并且100-299范围的号码指示成功，所以你只能看到400-599的错误号码。 BaseHTTPServer.BaseHTTPRequestHandler.response是一个很有用的应答号码字典，显示了RFC 2616使用的所有的应答号。这里为了方便重新展示该字典。（译者略） 当一个错误号产生后，服务器返回一个HTTP错误号，和一个错误页面。你可以使用HTTPError实例作为页面返回的应答对象response。这表示和错误属性一样，它同样包含了read,geturl,和info方法。 复制代码 代码如下: >>>req = urllib2.Request('/fish.html') >>> try: >>>urllib2.urlopen(req) >>>except URLError, e: >>>print e.code >>>print e.read() >>> 复制代码 代码如下: 404 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""/TR/html4/loose.dtd"> <?xml-stylesheet href="./css/ht2html.css" type="text/css"?> <html><head><title>Error 404: File Not Found</title> ...... etc... Wrapping it Up包装 所以如果你想为HTTPError或URLError做准备，将有两个基本的办法。我则比较喜欢第二种。 第一个： 复制代码 代码如下: from urllib2 import Request, urlopen, URLError, HTTPError req = Request(someurl) try: response = urlopen(req) except HTTPError, e: print 'The server couldn't fulfill the request.' print 'Error code: ', e.code except URLError, e: print 'We failed to reach a server.' print 'Reason: ', e.reason else: # everything is fine 注意：except HTTPError 必须在第一个，否则except URLError将同样接受到HTTPError。 第二个： 复制代码 代码如下: from urllib2 import Request, urlopen, URLError req = Request(someurl) try: response = urlopen(req) except URLError, e: if hasattr(e, 'reason'): print 'We failed to reach a server.' print 'Reason: ', e.reason elif hasattr(e, 'code'): print 'The server couldn't fulfill the request.' print 'Error code: ', e.code else: # everything is fine info and geturl urlopen返回的应答对象response(或者HTTPError实例)有两个很有用的方法info()和geturl() geturl -- 这个返回获取的真实的URL，这个很有用，因为urlopen(或者opener对象使用的)或许 会有重定向。获取的URL或许跟请求URL不同。 info -- 这个返回对象的字典对象，该字典描述了获取的页面情况。通常是服务器发送的特定头headers。目前是httplib.HTTPMessage 实例。 经典的headers包含"Content-length"，"Content-type"，和其他。查看Quick Reference to HTTP Headers获取有用的HTTP头列表，以及它们的解释意义。 Openers和Handlers 当你获取一个URL你使用一个opener(一个urllib2.OpenerDirector的实例，urllib2.OpenerDirector可能名字可能有点让人混淆。)正常情况下，我们 使用默认opener -- 通过urlopen,但你能够创建个性的openers，Openers使用处理器handlers，所有的“繁重”工作由handlers处理。每个handlers知道 如何通过特定协议打开URLs，或者如何处理URL打开时的各个方面，例如HTTP重定向或者HTTP cookies。 如果你希望用特定处理器获取URLs你会想创建一个openers，例如获取一个能处理cookie的opener，或者获取一个不重定向的opener。 要创建一个 opener,实例化一个OpenerDirector，然后调用不断调用.add_handler(some_handler_instance). 同样，可以使用build_opener，这是一个更加方便的函数，用来创建opener对象，他只需要一次函数调用。 build_opener默认添加几个处理器，但提供快捷的方法来添加或更新默认处理器。 其他的处理器handlers你或许会希望处理代理，验证，和其他常用但有点特殊的情况。 install_opener 用来创建（全局）默认opener。这个表示调用urlopen将使用你安装的opener。 Opener对象有一个open方法，该方法可以像urlopen函数那样直接用来获取urls：通常不必调用install_opener，除了为了方便。

---