Pass Werkzeug/WSGI middleware bytestrings, not unicode. (#6180)

* Pass Werkzeug/WSGI middleware bytestrings, not unicode.

This fixes a bug that prevents website routing to non-ascii routes, such as
will be automatically created by items with non-ascii characters in their
names.

Werkzeug/WSGI actually does careful decoding of URLs passed to it which
ensure they are in the correct format internally. However, using a non-ascii
URL was causing a unicode error and exceptions.

In app.py, unicode_literals is in effect. SharedDataMiddleware and
StaticDataMiddleware instances are created to deal with files in 'assets'
and 'files', respectively. The paths passed need to be bytestrings; however,
due to the use of unicode, these were passed as unicode. This was causing a
later exception when using a (unicode) string method on the decoded URL
string. By explicitly passing bytestrings, this is avoided and everything
works as expected.

* Instead of calling str, call .encode('ascii') method for compatibility with Python3.

* Unicode URL WSGI fix: After testing, it is actually the key not the value of
the export that matters, however both can be wrapped in str() to get 'bytes'
in Python 2 and unicode in Python 3 (which WSGI seems to expect).

frappe/app.py

@@ -219,11 +219,11 @@ def serve(port=8000, profile=False, site=None, sites_path='.'):
 
 	if not os.environ.get('NO_STATICS'):
 		application = SharedDataMiddleware(application, {
-			'/assets': os.path.join(sites_path, 'assets'),
+			str('/assets'): str(os.path.join(sites_path, 'assets'))
 		})
 
 		application = StaticDataMiddleware(application, {
-			'/files': os.path.abspath(sites_path)
+			str('/files'): str(os.path.abspath(sites_path))
 		})
 
 	application.debug = True