uWSGI 1.9.18

更新日志 [20131011]

License变更

uWSGI的这个版本是1.9版本树第一个使用GPL2 + linking exception而不是简单的GPL2的版本。

这个新的license应该会避免在把uWSGI作为共享库使用(或者使用非GPL2兼容的库链接它)的时候的任何问题

记住:如果你需要对uWSGI进行闭源修改,那么你可以购买一个商业license。

错误修复

  • 修复大端机器上的uwsgi原生协议支持
  • 为arm修复jvm构建系统 (Jorge Gallegos)
  • 修复zlib管理中由cppcheck发现的内存泄漏
  • 在每一个emperor glob迭代chdir()
  • 正确遵循–force-cwd
  • 修复ia64/Linux编译 (Jonas Smedegaard/Riccardo Magliocchetti)
  • 修复ruby rvm路径解析顺序
  • 在守护进程的SIGTERM后添加waitpid() (Łukasz Mierzwa)
  • 修复–idle后的Pid编号 (Łukasz Mierzwa)
  • 修复/改进cheaper内存限制 (Łukasz Mierzwa)
  • 正确关闭网关中的继承socket
  • 修复mmap()中对MAP_FAILED的检查 (而不是NULL)
  • 修复FastCGI非阻塞请求体read() (由Arkaitz Jimenez提供补丁)
  • 修复attach.py脚本
  • 避免因不符合标准的PSGI响应头引发的崩溃
  • 在非lazy时,(即使是在非apps模式下)运行python自动重载器

新特性

最小构建配置文件

尽管uWSGI核心的内存使用量一般在1.8和2.5兆之间,但在一些用例下,你会想要一个最低限度的核心以及一组嵌入式插件。

例子诸如用户不利用uWSGI的指定特性,或者是uWSGI使用的库与其他库(例如openssl或者zeromq)的名字冲突这种情况。

添加了一堆“最小化”构建配置文件:

  • pyonly (构建一个最小化的CPython WSGI服务器)
  • pypyonly (构建一个最小化的PyPy WSGI服务器)
  • plonly (构建一个最小化的PSGI服务器)
  • rbonly (构建一个最小化的Rack服务器)

唯一支持的配置格式是.ini,而内部路由和legion子系统并未内置。

例如,如果你想要通过pip安装最小uWSGI二进制文件:

  1. UWSGI_PROFILE=pyonly pip install uwsgi

重要:最小构建配置文件并不会提高性能,由于设计uWSGI的方式,未使用的特性并不会消耗CPU。最小构建配置文件只影响最终的二进制文件大小

Auto-fix modifier1

为非python插件设置modifier1是及其烦人的 (你往往会忘掉它)。

现在,如果请求的modifier1是0,但未加载python插件 (或者没有已加载的python应用),那么第一个配置的应用将会被替代设置 (除非你使用–no-default-app来禁用这个特性)。

这意味着,现在,你可以运行:

  1. uwsgi --http-socket :9090 --psgi myapp.pl

而不是

  1. uwsgi --http-socket :9090 --http-socket-modifier1 5 --psgi myapp.pl

显然,试着总是设置modifier1,这只是一个便捷方式

Perl自动重载器

–perl-auto-reload选项允许psgi插件在每次请求之后检查已修改的模块。它以扫描的频率(以秒为单位)作为参数。

该扫描在服务了一个请求之后进行。它是次优的,但是它也是最安全的选择。

“raw”模式 (预览技术,只用于CPython)

当在Unbit着手于一个新的服务器端项目时,我们有需要公开使用一个非常特别的协议的web应用 (uWSGI不支持它们中任何一个)。

我们的第一个方式是将新的协议作为插件添加,但很快我们就意识到这太具体了。因此,我们决定引入RAW模式。

Raw模式允许你直接在应用可调用对象中解析请求。与在可调用对象中获得CGI变量/头列表相反,accept()之后你只获得文件描述符。

然后你可以自由地对那个文件描述符进行read()/write()。

  1. import os
  2. def application(fd):
  3. os.write(fd, "Hello World")
  1. uwsgi --raw-socket :7070 --python-raw yourapp.py

Raw mode禁用请求日志记录。目前,我们只对CPython支持,如果我们得知其他语言支持(或者感兴趣),那么我们肯定会添加支持。

重要:raw模式并非标准,因此别期待会应用任何中间件或者常见使用模式。将其当成一个低层次的socket封装器使用。

对于WSGI响应,CPython缓存协议的可选的非标准支持

作者:yihuang,在INADA Naoki (methane)的帮助下

WSGI (PEP333/3333)对于响应的有效对象类型是非常清晰的:str用于python2,bytes用于python3

uWSGI (大量使用mod_wsgi作为参考) 总是强制这样的行为,因此,“怪异的”模式,例如返回不支持的字节数组。这样的使用在纯python应用服务器会有点无意识支持,只是因为它们在其之上简单调用write(),或者因为在返回之前将它们转换成字符串 (非常低效)

yihuang提出的补丁建议使用 CPython C api公开的低层次的缓存协议。字符串 (python2中) 和字节 (python3中) 支持该缓存协议,因此,它的使用是透明的,并且也保证向后兼容。 (给CPython C api专家:是哒,我们同时支持老的和新的缓存协议)

这是一个非标行为,你必须通过–wsgi-accept-buffer来自愿启用它。

小心使用,因为它可能会掩盖错误以及/或者错误行为。

注意:如果你尝试使用1.9.18-dev,那么你可能会注意到这个选项是默认被启用的。它是一个错误。多亏了Graham Dumpleton (mod_wsgi作者)指出。

Emperor和配置改进

关于作者:Matthijs Kooijman

已改进配置系统,相对于strict模式,它甚至更加一致 (提醒:使用–strict,你基本上为未知选项检查配置文件,避免了由于错别字引发的头疼问题)。

新增了魔术变量,公开原始配置文件的名字 (这在Emperor模式下简化了模板),看一看:https://github.com/unbit/uwsgi-docs/blob/master/Configuration.rst#magic-variables

使用–emperor-cap选项,Emperor获得了Linux功能的支持。该选项以vassal作为root启动的时候,你想要保持的功能列表为参数:

  1. [uwsgi]
  2. emperor = /etc/uwsgi/vassals
  3. emperor-cap = setuid,net_bind_service

通过这个设置,你的vassal将只能够移除特权,并且绑定到<1024的端口

它的好基友是linux名字空间的CLONE_NEWUSER标志,现在uWSGI完全支持它:

  1. [uwsgi]
  2. emperor = /etc/uwsgi/vassals
  3. emperor-use-clone = user
  4. emperor-cap = setuid,net_bind_service

这将会为vassal创建一个新的带有更少特权的root用户(CLONE_NEWUSER是非常难以理解的,但理解它的最好的方式是将其视为带有专有功能的新的root用户)

构建系统改进

已改进构建系统,它现在可以运行时链接自定义资源了。对于低层次的钩子,它运行良好:

  1. // embed_me.c
  2. #include <stdio.h>
  3.  
  4. void hello_i_am_foobar() {
  5. printf("I Am foobar");
  6. }

现在,我们可以一次性链接到这个文件到主uWSGI二进制文件上:

  1. UWSGI_ADDITIONAL_SOURCES=embed_me.c make

然后,你可以自动访问你的钩子:

  1. uwsgi --http-socket :9090 --call-asap hello_i_am_foobar

最后,Riccardo Magliocchetti重写了构建脚本,使用optparse,而不是原始/老式的sys.argv解析

插件化’模式(scheme)’管理

模式(scheme)是uWSGI uri的前缀部分。当你这样

  1. uwsgi --ini http://foobar.local:9090/test.ini

http://就是模式,发信号给uWSGI,告诉它必须通过http下载配置文件。

直到现在,那些’模式(scheme)’都是硬编码的。现在,它们作为茶具被公开出来,因此你可以添加更多的模式(scheme)了 (或者覆盖默认的)。

新的系统也已被应用到PSGI插件了 (抱歉啦,我们确保只有perl开发者才会明白那种诗意 :P),因此,你可以做这样的事:

  1. uwsgi --http-socket :1717 --psgi http://yourapps.local/dancer.pl

或者

  1. ./uwsgi --binary-append-data yourapp.pl > blob001
  2. cat blob001 >> ./uwsgi
  3. ./uwsgi --http-socket :1717 --psgi data://0

挂载点检查

可能很难理解为什么一个应用服务器应该检查挂载点。

正如几年前,理解如何在用户空间内写入文件系统是件傻事。

因此,看看这篇关于用uWSGI管理Fuse文件系统的文章: https://uwsgi-docs.readthedocs.io/en/latest/tutorials/ReliableFuse.html

初步libffi插件

随着为公开的钩子嵌入c库变得越来越普遍,我们开始致力于libffi集成,允许传给钩子安全(而理智)的参数。很快就会有相关内容了。

对kFreeBSD的官方支持

官方支持Debian/kFreeBSD。

你甚至可以也使用FreeBSD jails了!!!

FreeBSD Jails

可用性

uWSGI 1.9.18于2013年10月11日发布

你可以从下面地址下载它:

http://projects.unbit.it/downloads/uwsgi-1.9.18.tar.gz