WSGI Python Web Server Gateway Interface 规范学习

由于Python的灵活性，提供了多种方式可以作为服务端语言，包括Python编写的服务器（Medusa）、Python处理模块（mod_python)，或者使用CGI、FastCGI方式触发Python脚本。 为了能够编写更通用的Web端程序，提出了WSGI接口作为标准接口规范，类似于Java中的Serverlet，一旦编写完成后，可以运行在不同的App框架中。

WSGI接口涉及两个方面：一面是：服务器(server)或网关(gateway)，相对别一面是：应用程序(application)或框架(framework)。服务端运行由应用程或框架提供的可执行的对像实例，至于这个可执行对象的是如果获得的细节，不在WSGI规范定义之内，而是同server或gataway去处理。

Application/Framework 端

Application端是一个callable term，可以是function、class、method等，接收两个参数environ、start_response。当application被server调用时，必须返回一个iterable的bytestrings或者是zero（可以使用yield返回一个生成器）。

WSGI 是为框架或服务器开发人员提供的工具，而不是为应用人员提供的。

When called by the server, the application object must return an iterable yielding zero or more byte strings.

服务器调用时，应当以无缓存的形式将产生的内容发送给客户端。

方法：len()、close()

Server/Gateway 端

中间件 Middleware 扮演两个角色

Middleware常扮演以下角色：

• 根据目标URL将请求路由到不同的Application进行处理
• 允许多个Application或Framework运行在相同的进程中
• 通过网络内的请求转发实现负载均衡和远程处理
• 实现内容的后续处理，例如XSL样式表

中间件的存在对于服务端和应用端应该都是透明的。

environ 变量

environ 是一个字典变量。

变量名	备注
REQUEST_METHOD	HTTP请求方法，GET、POST、PUT，不能为空
SCRIPT_NAME	脚本名称，可以为空
PATH_INFO	请求URL中的一部分，可以为空
QUERY_STRING	请求URL中问号（？）之后的部分，可以为空
CONTENT_TYPE	请求中的Content_Type字段，可以为空
CONTENT_LENGTH	请求中的Content_Length，可以为空
SERVER_NAME , SERVER_PORT	不能为空
SERVER_PROTOCOL	客户端发送请求采用的协议及版本
HTTP_ 变量	客户端请求头中的参数，可以为空

CGI方式需要提供的参数略有不同，具体可以参考PEP3333

A WSGI-compliant server or gateway should document what variables it provides, along with their definitions as appropriate. Applications should check for the presence of any variables they require, and have a fallback plan in the event such a variable is absent.

Input、Error流

服务器端必须支持以下几个方法

方法	流
read(size)	Input
readline()	Input
readlines(hint)	Input
iter()	Input
flush()	errors
write(str)	errors
writelines(seq)	errors

start_response()

方法示例start_response(status, response_headers, exec_info = None)。

start_response 接收两个参数start_response(status, response_headers)，status是状态返回信息，诸如“200 OK”或者“404 Not Found”，纯文本，不能包含任何控制符号。response_headers是一个形如(header_name, header_value)的tuples，必须是Python的List。header_name必须是RFC2616中定义的名称，header_value不包含结束符号及任何控制符号，包括换行等。

一般来说，服务器端负责确保发送的header的正确性，如果应用忽略了某个http头参数，那么服务器应该给补充进去。

服务端应该检查是否向客户端发送了保持链接的头参数，如果发现，应该抛出错误。

Content-Length 头的处理

如果应用端提供了 Content-Length 请求头，服务端不应当传递超过这个长度的内容。处理方式是停止发送内容，或产生一个报错。如果没有提供足够的内容，则应正常关闭链接不产生错误。

如果没有提供 Content-Length 头，则服务端可以自己决定采用哪种处理方式，最简单的就是响应结束后关闭链接。某些情况下，服务端可以自己产生 Content-Length , 或者尽量避免关闭链接。如果服务端和客户端都支持 HTTP/1.1 分块编码，则服务端需要为每个块提供一个 Content-Length。

缓存和流处理 Buffering and Streaming

write() callable

一些编程框架提供了缓存的 write() 函数以及一个 flush() 函数，用于刷新缓存，但是很遗憾标准的WSGI无法实现这个需求。但WSGI仍提供了一个特殊 write() 函数，来实现这些迫切的需求。

write() 由 start_response 返回，接收一个参数。一个应用必须返回一个 iterable 对象。

错误处理