Tracker 服务器源码分析之三：HTTPHandler 类
作者：小马哥
日期：2004-6-7
本篇文章分析 HTTPHandler类，它在 HTTPHandler.py 文件中。
上一篇我们讲到， RawServer 只负责网络 I/O，也就是从网络上读取和发送数据，至于读到的数据如何分析，以及应该发送什么样的数据，则交给 Handler 类来处理。如果是用 c++ 来实现的话，那么 Handler 应该是一个接口类（提供几个虚函数作为接口），但是 python 动态语言的特性，并不需要专门定义这么一个接口类，所以实际上并没有 Handler 这么一个类。任何一个提供了以下成员函数的类，都可以作为一个 Handler 类来与 RawServer 配合，它们是：
external_connection_made()：在建立新的连接的时候被调用
data_came_in()：连接上有数据可读的时候被调用
connection_flushed()：当在某个连接上发送完数据之后被调用
HTTPHandler 就是这样一个 Handler 类，它具备以上接口。
HTTPHandler 代码很少，因为它把主要工作又交给 HTTPConnection 了。
我们看 HTTPHandler 类的这几个函数：
l external_connection_made()：
每当新来一个连接的时候，就创建一个 HTTPConnection 类。
l data_came_in()：
当连接上有数据可读的时候，调用 HTTPConnection::data_came_in()。我们接下去看HTTPConnection::data_came_in()。
我们知道，BT client端与 tracker服务器之间是通过tracke HTTP 协议来进行通信的。HTTP协议分为请求（request）和响应（response），具体的协议请看相关的 RFC 文档。我这里简单讲一下。
对 tracke 服务器来说，它读到的数据是 client 端的HTTP 请求。
HTTP请求以行为单位，行的结束符是“回车换行”，也就是 ascii 字符 “\r”和“\n”。
第一行是请求的 URL，例如：
GET /announce?ip=aaaaa;port=bbbbbbb HTTP/1.0
这行数据被空格分为三部分，
第一部分GET表示命令，其它命令还有POST、HEAD等等，常用的就是GET了。
第二部分是请求的URL，这里是 /announce?ip=aaaaa;port=bbbbbbb。如果是普通的上网浏览网页，那么URL 就是我们要看的网页在该web服务器上的相对路径。但是，这里的URL仅仅是交互信息的一种方式，client 端把要报告给 tracker 的信息，放在URL中，例子里面是 ip 和 port，更详细的信息请看“BT协议规范”中 tracker 协议部分。
第三部分是HTTP协议的版本号，在程序中忽略。
接下来的每一行，都是HTTP协议的消息头部分，例如：
Host:www.sina.com.cn
Accept-encoding:gzip
通过消息头，tracker服务器可以知道 client端的一些信息，这其中比较重要的就是 Accept-encoding，如果是 gzip ，那么说明 client 可以对 gzip 格式的数据进行解压，那么tracker服务器就可以考虑用 gzip 把响应数据压缩之后再传回去，以减少网络流量。我们可以在代码中看到相应的处理。
在消息头的最后，是一个空行，表示消息头结束了。对GET和HEAD命令来说，消息头的结束，也就意味着整个client端的请求结束了。而对 POST 命令来说，可能后面还跟着其它数据。由于我们的 tracker服务器只接受 GET 和 HEAD 命令，所以在协议处理过程中，如果遇到空行，那么就表示处理结束。
HTTPConnection::data_came_in() 用一个循环来进行协议分析：
首先是寻找行结束符号：
i = self.buf.index('\n')
（我认为仅仅找 “\n”并不严谨，应该找 “\r\n”这个序列）。
如果没有找到，那么 index() 函数会抛出一个异常，而异常的处理是返回 True，表示数据不够，需要继续读数据。
如果找到了，那么 i 之前的字符串就是完整的一行。于是调用协议处理函数，代码是：
self.next_func = self.next_func(val)
在 HTTPConnection 的初始化的时候，有这么一行代码：
self.next_func = self.read_type
next_func 是用来保存协议处理函数的，所以，第一个被调用的协议处理函数就是 read_type()。它用来分析client端请求的第一行。在 read_type() 的最后，我们看到：
return self.read_header
这样，在下一次调用 next_func 的时候，就是调用 read_header()了，也就是对 HTTP 协议的消息头进行分析。
下面先看 read_type()，
它首先把 GET 命令中的 URL 部分保存到 self.path中，因为这是 client端最关键的信息，后面要用到。
然后检查一下是否是GET或者HEAD命令，如果不是，那么说明数据有错误。返回None，否则return self.read_header
接下来我们看read_header()，
这其中，最重要的就是对空行的处理，因为前面说了，空行表示协议分析结束。
在检查完 client 端是否支持 gzip 编码之后，调用：
r = self.handler.getfunc(self, self.path, self.headers)
通过一层层往后追查，发现 getfunc() 实际是 Tracker::get()，也就是说，真正对 client 端发来的请求进行分析，以及决定如何响应，是由 Tracker 来决定的。是的，这个 Tracker 在我们tracker 服务器源码分析系列的第一篇文章中就已经看到了。在创建 RawServer 之后，马上就创建了一个 Tracker 对象。所以，要了解 tracker 服务器到底是如何工作的，需要我们深入进去分析 Tracker 类，那就是我们下一篇文章的工作了。
在调用完 Tracker::get() 之后，返回的是决定响应给 client 端的数据，
if r is not None:
self.answer(r)
最后，调用 answer() 来把这些数据发送给 client 端。
对 answer() 的分析，我们在下一篇分析 Tracker类的文章中一并讲解。
l connection_flushed()：
tracker服务器用的是非阻塞的网络 I/O ，所以不能保证在一次发送数据的操作中，把要发送的数据全部发送出去。
这个函数，检查在某个连接上需要发送的数据，是否已经全部被发送出去了，如果是的话，那么关闭这个连接的发送端。（为什么仅仅关闭发送端，而不是完全关闭这个连接了？疑惑）。
