lighttpd请求处理的过程:
1.服务器与客户端建立连接后,连接进入CON_STATE_REQUEST_START状态,服务器做一些标记,如连接开始的时间等。
2.连接进入CON_STATE_READ状态,服务器从连接读取HTTP头并存放在con->requeset.request中。若一次调用没能读取全部数据,连接的状态将继续为READ,继续等待剩下的数据可读。
在对joblist进行处理的时候,依然会调用connecion_handle_read_state函数进行处理,函数中通过con->is_readable来判断是否有数据可读,如果没有,则只是处理一下以前已经读取的数据。
3.数据读取完之后,连接进入CON_STATE_REQUEST_END状态。
4.在REQUEST_END阶段,调用http_request_parse函数解析request请求。
函数首先解析Request line,解析出来的结果存放在con->request.http_method, con->request.http_version和con->request.uri中(前两个变量都是枚举类型,后一个是个buffer)。
解析完request line后,开始分析header lines。找到一个header field name后,就和所有已经定义的field name比较,看看是哪个。确定之后,就将field name和value保存到con->request.headers中。request.headers是一个array类型变量,存放的是data_string类型数据。其中,data_string的key是filed name,value就是field的成员。
5.解析完之后判断此次连接是否有POST数据,有则读取POST数据,否则进入HANDLE_REQUEST状态。
6.如果有POST数据要读,连接进入READ_POST状态。
READ_POST状态的处理和READ状态类似。
在connection_state_mechine函数中,这两个switch分支一样。在connection_handle_read_state函数中,前半部分读取数据是一样的,后面处理数据时才分开。
对于POST数据,由于数据可能很大,这时候可能会用到临时文件来存储。在程序中,作者对于小于64k的数据,直接存储在buffer中,大于64k则存储在临时文件中。在向临时文件写数据时,每个临时文件只写1M的数据。数据大于1M就再打开一个临时文件。
POST数据保存在con->requeset_content_queue,这是一个chunkqueue类型的成员变量,它是chunk结构体的链表:
~~~
typedef struct
{
chunk *first;
chunk *last;
/**
* 这个unused的chunk是一个栈的形式。
* 这个指针指向栈顶,而chunk中的next指针则将栈连 接起来。
*/
chunk *unused;
size_t unused_chunks;
array *tempdirs;
off_t bytes_in, bytes_out;
} chunkqueue;
~~~
unused成员是栈形式的链表,unused指向栈顶。它用来存储不用的chunk结构体,如果需要chunk,则先从这个栈中查找有无空闲的。如果chunk不使用了,可以加到栈顶。这样可以减少内存分配的时间,提高程序的效率。unused_chunks标记栈中有多少数据。
chunk的定义:
~~~
typedef struct chunk
{
enum { UNUSED_CHUNK, MEM_CHUNK, FILE_CHUNK } type;
/* 内存中的存储块或预读缓存 */
buffer *mem;
/* either the storage of the mem-chunk or the read-ahead buffer */
struct
{
/*
* filechunk 文件块
*/
buffer *name;/* name of the file */
off_t start;/* starting offset in the file */
off_t length;/* octets to send from the starting offset */
int fd;
struct
{
char *start;/* the start pointer of the mmap'ed area */
size_t length;/* size of the mmap'ed area */
off_t offset; /* start is <n> octet away from the start of the file */
} mmap;
int is_temp;/* file is temporary and will be
deleted if on cleanup */
} file;
off_t offset;/* octets sent from this chunk the size of the
* chunk is either -mem-chunk: mem->used - 1 file-chunk: file.length */
struct chunk *next;
} chunk;
~~~
chunk用来表述一块存储空间。这个存储空间可能在内存中,也可能在文件中。
type成员标记这个块是内存的还是文件的。
mem成员指向内存中的存储空间(实际上是一个buffer)。
file结构体则表示在文件中的存储空间(程序首先使用mmap函数将文件映射到内存中,mmap结构体的start成员保存映射到内存中的地址,于是对于文件的操作就可以像内存一样)。
7.读取完数据之后,进入HANDLE_REQUEST状态,此时请求已经解析完毕,本状态需要决定如何处理请求。
该状态调用http_response_prepare函数,然后根据函数的返回值进行相应的处理(http_response_prepare函数定义在response.c文件中,函数中调用了很多plugins_call_handle_xxxx函数,插件系统的接口函数主要是在这个函数中调用,这个函数也是服务器和插件系统交互的地方)。
在http_response_prepare函数中,通过对url的解析,逐步的调用插件来处理。对url解析的结果存放在con->uri中:
~~~
typedef struct
{
buffer *scheme; //http , https and so on
buffer *authority; //user:password
buffer *path; //www.xxx.com/xxx/xxxx.html
buffer *path_raw; //www.xxx.com
buffer *query; //key1=data1&key2=data2
} request_uri;
~~~
uri的定义为:(scheme)://(authority)(path)?(query)#fragment。
如:
[http://user:passwd@www.google.com/pages/index.html?key1=data1&key2=data2#frag](http://user:passwd@www.google.com/pages/index.html?key1=data1&key2=data2#frag)
解析之后:
~~~
scheme = http
authority = user:passwd
path = www.google.com/pages/index.html
path_raw = 未进行解码的path
query = key1=data1&key2=date2
~~~
注意,在浏览器向服务器发送url请求的时候,会对其中的保留字符和不安全字符进行编码(参见RFC2396),比如汉字。编码的形式是% HEX HEX,即一个%加两个十六进制数。服务器在接到请求之后,要对这些编码过的字符进行解码。path_raw中保存的是还没解码的url,path保存的是已解码的url。
对fragment服务器直接抛弃,因为fragment是浏览器使用的。
当解析出url中的path之后,服务器调用插件的plugins_call_handle_uri_raw函数,插件根据未解码的url path进行处理。
如果没有插件进行处理,服务器调用插件的plugins_call_handle_uri_clean函数,它根据解码过的url path进行处理。
在这里,服务器根据解析出来的url地址直接将请求转发给插件,而不需要自己对请求进行处理。
当请求仍然没有被处理时,说明这个请求必须要在这被处理。服务器调用插件的plugins_call_handle_docroot函数对处理请求时的根目录进行设置。对于不同种类的资源,可以设置不同的根目录,提供一个虚拟服务器。接着,服务器根据根目录和请求的url地址,拼接出资源在本机上对应的物理地址。比如,doc root = /abc/root, url path = /doc/index.html,得到的物理地址就是/abc/root/doc/index.html。然后服务器调用插件的plugins_call_handle_physical函数,根据得到的物理地址进行相应的处理。最后,服务器调用插件的plugins_call_handle_subrequest_start函数和plugins_call_handle_subrequest函数进行最后的处理。
8.连接进入CON_STATE_RESPONSE_START状态,服务器准备给客户端的response,包括准备response头和写数据。
参考:
[http://www.cnblogs.com/kernel_hcy/archive/2010/04/07/1706587.html](http://www.cnblogs.com/kernel_hcy/archive/2010/04/07/1706587.html)