7erry

CVE-2010-2883 是 Adobe Reader 和 Acrobat 中的 CoolType.dll 库在解析字体文件 SING 表中的 uniqueName 项时存在的栈溢出漏洞，用户受骗打开了特制的 PDF 文件就有可能导致任意代码执行。这种 “打开 PDF 即刻中招” 的效果堪称 “简单暴力” 的典范，也使其作为漏洞而言非常经典

影响范围：
Adobe Reader 8.2.4 - 9.3.4

程序的本质就是指令+上下文。

作为一个 Web Application ，Flask 也必然有着自己的上下文。例如视图函数需要知道包括请求的方法，路径，参数等请求信息的上下文才能够正常的工作。如果你有过其它语言的编程经验，就会很容易想到通过在调用这些函数时在参数中传递相关的数据或这些数据的指针来为函数提供这些必要的上下文信息。如果这门语言支持 OOP ，那么这些请求相关的信息还可以被封装到请求的抽象类中。事实上，确实有不少框架是这样做的，例如 sanic 。但这样设计上下文的话，视图函数应该会长成这样

1
2
3
4

# demo.py
@app.route(path)
def view_function(request):
    ...

也就是说，视图函数应该有 request 这么一个参数才对，但从 Flask Demo 中我们并没有发现这样一个参数。显然，Flask 采用了另外一种不同的实现方式。

一个 Web 应用针对不同的请求路径会有不同的处理函数，而路由就是根据 HTTP 请求的 URL 找到对应处理函数的过程。Flask 的路由实现较为轻量，更为底层的路由处理逻辑由 WerkZeug 实现，在此系列博客中暂不进行深入的探讨，让我们先从经典的 Flask Demo 开始讨论

我们已经基本理解了 Flask 的框架原理，即 Flask 通过与 WerkZeug WSGI 框架进行交互实现 HTTP Web Server 所需要具备的功能，但这些框架原理的讨论实际上是将 Flask 框架视作为一个黑箱，或者说视作了 Web Application Framework 的一个实例为前提进行的。我们所探究的是较为一般的 Web Application Framework 与 HTTP Server 如何协同工作从而实现 Web Server 的方式，并基本了解了 Flask 如何作为 Web Application Framework 与 WSGI 交互以启动 WebServer 的。但我们仍不了解 Flask 在抛开 Web Application Framework 所需要做的基本工作以外，其工作流具体是什么样的。我们将路由匹配，上下文，异常处理的具体实现暂时忽略，单纯的从 Flask 接收到请求并响应的工作流程这一抽象层级上来看看 Flask 是如何工作的

当我写 Rust 时，我觉得自己像个天才。我稍后会告诉你为什么，但首先看一个简单的问题，这段代码正确吗？

When I write Rust , I feel like a genius . I’ll tell you why in a moment , but first a simple question . Is this code correct ?