wdhwg001

如果是直接复制流的话应该不会太慢啊，或者用 mkv 做容器？

作为 ASGI 用户，每次看到 WSGI 们纠结 Windows 就觉得有 Uvicorn 真好，Waitress 到现在连个 SSL 都不支持，Uvicorn 功能已经做到快和 Gunicorn 齐平了。

@catfan 我是说右划的时候看不到上一页的预览的问题。如果点击链接前顶栏是缩回去的，点击后又打开了，那么前后 webview 高度不一致会使得右划无预览。

希望可以滑条调整夜间模式的对比度。

另外一些菜单文字和图标的对比度在夜间模式下不统一。

以及，WebView 有右滑白屏的 Bug，是这样的：当上一页面离开时的 WebView 高度和当前的 WebView 高度不一致的时候，右滑会出现白屏，这里需要单独对这个 WebView 的 Bug 做调整。

还有一些界面交互上可以明显看得出想学 ios，但是却在许多小的地方是反直觉的，比如阅读模式下滑不能关闭，比如一个有 Grip 的设置栏不能上下滑等等。

另外基于私心，我比较希望地址栏编辑时可以左右拖拽滚动，并且拥有语法高亮。

滚轮不支持倾斜，需要配合侧键组合才能实现横向滚动。

async 的支持怎么样？

@abersheeran 但是也同样无法解决闭包不可靠的问题啊，你只能规定禁止 scope 深拷贝，并且规定禁止 scope["session"] = {}这样的操作。

@abersheeran 但是你的中间件需要调用内层的 Application，而 send 则是一层一层传递下去，直到最后一层 Application 才调用这个 callable 的，所以你不应该在中间件里直接执行这个 send，而是要把它传递到更深层的 ASGI Application 里：

```python
async def __call__(self, scope, receive, send):
session = {}
scope["session"] = session

await self.app(scope, receive, send)
```

这样一来，你就只能存一个 scope 的闭包：

```python
async def __call__(self, scope, receive, send):
session = {}
scope["session"] = session

async def send_wrapper(message):
# do something to store session
scope["session"]["saved"] = True # 这里的闭包是不可靠的
await send(message) # 但是这里是可靠的

await self.app(scope, receive, send_wrapper)
```

但是就像 ASGI 标准里描述的那样，Scope 是会被下一层 Application 复制的，这就使得内层如果真的复制了 Scope 的话，外层对 Scope 的闭包引用读取到的只会是脏数据。我仔细思考过了，觉得这里如果 ASGI 不做调整，ASGI 的实现也不保存 Application 栈的话（因为像 Django 的 Daphne 一样保存栈是很消耗资源的），这里应该是没有解决方案的。

可如果 ASGI 提供一个单例的上下文的话：


```python
async def __call__(self, scope, receive, send):
session = {}
scope["session"] = session # 把它存到一个请求期间的上下文变量，不一定是 Scope

async def send_wrapper(message, scope): # 这里接收一个请求期间的上下文变量，不一定是 Scope
# do something to store session
scope["session"]["saved"] = True # 这里就不是闭包而是普通地用参数了，所以是可靠的
await send(message) # 这里本来就是可靠的

await self.app(scope, receive, send_wrapper)
```

或者，如果修改 ASGI 的规定，使得 Scope 由一个 immutable 变为一个 mutable single instance 的话，任何一个地方都可以取到一个可靠的 Scope 的引用，也就不会存在复制的问题了。

@abersheeran 我试了一下，结果倒是挺遗憾的，Python 里的正则的性能与捕获组的数量是呈线性关系的，与捕获组之间的包含关系无关。所以，将树展开成正则组的操作应该是仅在树的同级节点的时候可以通过合并获得性能提升，超过同级的情况下就是 Python 的语言性能和正则引擎的执行效率之间的撕逼取舍了。

我个人不倾向于使用换语言的方式实现这个，因为你似乎还没完全榨干 Python 呢。

将上下文传入 receive 和 send 是有意义的，比如不然的话，你怎样使用纯 ASGI 中间件实现一个干净的 Session 呢？ Session 的读取发生在__call__期间，而存储和 cookie 的更新则发生在 send 期间，而这之间则需要一个上下文去保存 Session 中的信息吧。