Question

我有一个简单的裸WSGI应用程序：

def application(environ, start_response):
    start_response('200 OK', [('Content-Type','text/html')])
    print('PATH_INFO:', environ['PATH_INFO'])
    return [b'<p>Hello World</p>']

if __name__ == '__main__':
    from wsgiref import simple_server
    server = simple_server.make_server('0.0.0.0', 8080, application)
    server.serve_forever()

我提出了两个要求：

C:\>curl "http://localhost:8080/<foo>"
<p>Hello World</p>
C:\>curl "http://localhost:8080/%3Cfoo%3E"
<p>Hello World</p>

我得到了这个输出：

C:\code>python foo.py
PATH_INFO: /<foo>
127.0.0.1 - - [09/Mar/2014 13:48:39] "GET /<foo> HTTP/1.1" 200 18
PATH_INFO: /<foo>
127.0.0.1 - - [09/Mar/2014 13:48:47] "GET /%3Cfoo%3E HTTP/1.1" 200 18

即使客户端请求/foo，也请查看我的应用程序如何获取URL解码路径/%3Cfoo%3E。

它表明wsgiref.simple_server确保我的应用程序始终在environ['PATH_INFO']中获取URL解码的路径。

但我无法在PEP-3333的任何地方找到这种行为。能否请您指出记录此行为的官方文档？

Answer 1

如果服务器使其可用，来自实际HTTP请求行的REQUEST_URI值将为：

REQUEST_URI: '/%3Cfoo%3E'

即使您使用了以下情况，情况也许如此：

curl "http://localhost:8080/<foo>"

因为curl会在发送之前对URL进行编码以使用％escapes。

我认为REQUEST_URI不是任何RFC所涵盖的，而是由许多服务器提供的变量。您不能依赖它的存在，所以不要编写您的WSGI应用程序以依赖它存在。

Web服务器将在处理之前解码REQUEST_URI中的％escapes。因此，最终将在PATH_INFO中的结果将始终为：

PATH_INFO: '/<foo>'

解码由WSI构建的CGI和相关RFC覆盖。

参见例如：

为什么我的WSGI应用程序总是在environ ['PATH_INFO']中获得URL解码路径？

1 个答案: