python cgi 教程,python编写cgi服务端
本文主要通过Python中的CGI接口和应用实例来解释什么是WSGI。有需要的朋友可以借鉴一下，希望能有所帮助。祝大家进步很大，早日升职加薪。
00-1010前言为什么是WSGI？WSGI实现概述1)应用程序端2)服务器端3)作为中间件的其他资源：
目录
今天在git.oschina首页看到他们推出了一个演示平台，其中Python的演示平台支持WSGI接口的应用。虽然这个演示平台连自己提供的例子都无法运行，但还是成功的激起了我对WSGI的好奇心。了解一下这个机制，总结如下。如有不妥，请指正。
前言
各位写过web应用的朋友，你应该了解CGI。我们知道，CGI的整个过程就是“通用网关接口”，即“通用网关接口”。没错，这里的WSGI就是只针对Python的web应用接口“Python Web服务器网关接口”。通过这个类比，我们一定对他的立场有所了解。
它只是一个接口定义：它不负责服务器或web应用程序的实现，它只是双方接口的一个协议。因此，它不是另一个WEB应用程序框架。一般来说，WEB应用框架只相当于WSGI web应用的一个实现。
这样有什么好处？人教版0333中的解释是，为了实现类似Java Servelet的API，遵循该接口的应用具有更广泛的适用性。是的，有了这个接口，你就不用考虑服务器是如何支持Python实现——的了。无论是“直接用Python实现的服务器”、“嵌入Python的服务器”还是“通过网关接口(CGI，FastCGI.)”，3354应用具有良好的适用性。就像今天故事的开头，我们遇到了云平台，云平台提供了对WSGI接口的支持。然后，只要应用程序是基于WSGI的，那么应用程序就可以直接运行。
除此之外，WSGI的设计还提供了另一种可能，那就是中间件。或者，我们可以编写一些同时兼容服务器和应用程序的模块，部署在服务器端或者应用程序端，完成缓存、字符编码转换、应用程序根据url路由等功能。这种设计模式是WSGI降低服务器和应用程序之间耦合度的结果。同时从另一个角度大大提高了设计的灵活性。
为什么是 WSGI？
在最后一节中，简要介绍了WSGI。这里从应用、服务器、中间件三个方面对WSGI进行了深入的研究，让我们对它有了更具体的印象。
WSGI 实施概略
WSGI要求应用程序必须提供一个可以被调用的实体(PEP 0333使用Object，文档中专门解释了这与Object instance不同)。这个实体可以是函数、方法、类或带有__call__ method的对象实例。
下面是两个web应用实现的例子，一个是函数对象，一个是类对象：
def simple_app(环境，启动_响应):
状态=200正常
response _ headers=[( Content-type ， text/plain)]
start_response(状态，响应标题)
返回[你好，世界！n]
上面的函数只是用“200 ok”直接响应请求，并没有处理传入的参数environmdash。
;—里面是由 WSGI Server 端提供的各种 HTTP 请求参数。需要特别注意的是，这个函数在最后，返回的一个 list（用[]包含在内）以保证结果的 iterable。下面的 class 类似。
在下面例子中，AppClass 作为应用实体。当调用发生时，其实是对 class 进行了例化（ python 固有特性，可以参考后面 server 端的实现代码进一步理解），正如我们看到，这次调用（call）的返回值也是可迭代的——虽然只迭代一次（yield）。
class AppClass:
与上面两种情形不同，使用 object instance 作为应用实体时，需要为类定义添加 __call__ 方法，同时，参考上面使用 function 作为实体时情形，__call__ 方法的返回值需为 iterable（比如 return [ something ]）。
最后，不管我们的 app 是 function 还是 class， application 都需要处理两个参数，而且是两个位置相关的参数（不是命名参数），分别是：一个存放了 CGI 环境变量的 dictionary object，和一个可调用实体（需要给它三个位置相关的参数，两个必须，一个可选）。
其中，可调用实体（前例中的 start_response）必须调用一次，两个必须的参数分别为 HTTP Response的状态（str 类型） 和 HTTP Response Header（list of tuples）；
一个可选的参数exc_info，必须是 Python sys.exc_info() tuple，只有在出错需要显示错误信息时使用。完整调用：start_response(status, response_headers，exc_info).
2）Server 端
下面是从 PEP 0333 拿来的一个简单的 WSGI 容器，适用于 Python 作为某 WEB Server 上 CGI 时的应用情形。
import os, sys
上面的容器，大概实现了：
a）将 CGI 环境变量放入 dictionary object （environ）中，供 Application 实体使用；
b）定义了 start_response 方法，供 Application 实体调用；
c）调用 application 实体，对 web 请求进行处理；
d）将 application 的返回结果，以及通过 start_response 设置的 HTTP Response HEADER，写到 stdout ——像其他 CGI 一样，实际上是被发往网页。
3） 作为 middleware
因为 WSGI 的宽松耦合的特性，我们可以轻松的在 Application 和 Server 之前插入任何的中间插件，在不需要改动 Server 和 Application 的前提下，实现一些特殊功能。但是，这种放在 Server 和 Application 中间的模块，并不是这里要讲的 middleware ；或者，这只能算是一种特殊的 middleware，因为它仅仅是实现了 PEP 0333 中 middleware 定义的 Application 侧的功能。这种仅实施在一侧的 middleware，需要在发布时，特别的声明。
PEP 0333 中约定，中间件是一些即可以在 Server 端实施，又可以在 Application 端实施的模块。所以，在设计的时候，对两边的特性都要做适当考虑。幸好，WSGI 接口设计的足够简单。
class Router():
简单解释一下：
- 作为 Application 时，我们用 Router 实例化一个对象。然后对 PATH-APP 进行注册，根据不同的 PATH，我们要进一步选择哪个 App。接着，就是把 router.route() 喂给 Server ，作为 Application 侧的可调用实体。有请求到来时，根据已经注册的 PATH-APP 对选择应用并执行。
- Server 端类似，我们要先实例化并完成注册。然后，比如，拿我们上一小节实现的 WSGI 容器为例，我们需要修改 result = router.route(environ, start_response)，同样完成了router的功能。
下面是另外一个，实现了 postprocessor 的一个例子，在 Application 返回的 HTTP Header 里面再加一个 Header。
def myapp(environ, start_response):
这里通过改写传递给 Application 的实体，实现了 postprocess 的目的。
其他资源：
- WSGI 的一些详细资料，包括应用列表什么的：https://wsgi.readthedocs.io/en/latest/
- 支持 WSGI 的多线程 WEB 服务器，基于SimpleHttpServer：
http://www.owlfish.com/software/wsgiutils/
-Paste为构建以 WSGI 为基础的 WEB 应用程序或框架提供一个良好的基础
- 官方的 WSGI 实现参考：https://pypi.org/project/wsgiref/
- 啄木鸟社区的 WSGI 中文 wiki：https://wiki.woodpecker.org.cn/moin/WSGI
- 和 Paste 一样有名的基本架构：https://pypi.org/project/Pylons/1.0/
- 目前 Python 比较流行的三大 WEB 框架：TurboGears，Django，web2py。+1，代码在 K 级别的服务小框架：webpy。
- 另外三个据说高性能的 App 开发框架：Falcon、Tornado、Bootle.py.
- 还有个价格不错的 vps，恩：https://www.hostwinds.com/
以上就是通过Python中的CGI接口讲解什么是WSGI的详细内容，更多关于Python中CGI接口讲解WSGI的资料请关注盛行IT软件开发工作室其它相关文章！
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。