PATH_INFO is not urldecoded

[raylu]

with wsgiref,

import wsgiref.simple_server

def app(environ, start_response):
	start_response('200 OK', [('Content-Type', 'text/plain')])
	print('path info is', environ['PATH_INFO'])
	return [b'Hello, World!']

if __name__ == '__main__':
	wsgiref.simple_server.make_server('0.0.0.0', 5000, app).handle_request()

$ curl localhost:5000/你好 -v
> GET /%e4%bd%a0%e5%a5%bd HTTP/1.1
path info is /你好

however, with fastwsgi,

import fastwsgi

def app(environ, start_response):
	start_response('200 OK', [('Content-Type', 'text/plain')])
	print('path info is', environ['PATH_INFO'])
	return [b'Hello, World!']

if __name__ == '__main__':
	fastwsgi.run(wsgi_app=app, host='0.0.0.0', port=5000)

$ curl localhost:5000/你好 -v
> GET /%e4%bd%a0%e5%a5%bd HTTP/1.1
path info is /%E4%BD%A0%E5%A5%BD

I couldn't find anything in PEP-3333 about this, but https://werkzeug.palletsprojects.com/en/stable/wsgi/#raw-request-uri-and-path-encoding and https://falcon.readthedocs.io/en/stable/user/faq.html#why-is-my-url-with-percent-encoded-forward-slashes-2f-routed-incorrectly have assumed wsgiref's implementation

[remittor]

$ curl localhost:5000/你好 -v

GET /%e4%bd%a0%e5%a5%bd HTTP/1.1
path info is /%E4%BD%A0%E5%A5%BD

And I am happy with this behavior!

The main thing is that in such a case it would be like this (I haven't checked):

$ curl localhost:5000/%2E -v
path info is /.

[raylu]

but this makes it impossible to write an app that handles things like spaces and percent signs in a way that works on fastwsgi and any other wsgi server

if the client sends hi%20there, when my app runs on fastwsgi I see that string. when it runs on wsgiref or another server, it sees hi there. it's not safe to urldecode the path since it could have been hi%2520there

I ran into this when trying to implement a static path handler. I had files with spaces in the name and it broke on fastwsgi