At http://flask.pocoo.org/docs/api/#flask.request we read
The request object is an instance of the Request
subclass and provides all the attributes the Werkzeug defines.
The word Request
refers to http://werkzeug.pocoo.org/docs/wrappers/#werkzeug.wrappers.Request , where we read
A subclass of the Request
and Response
BaseRequest
and BaseResponse
and implement all Werkzeug BaseResponse
provides:
The word BaseRequest
refers to http://werkzeug.pocoo.org/docs/wrappers/#werkzeug.wrappers.BaseRequest , where we read
headers
WSGI headers surround as immutable EnvironHeaders
.
The word EnvironHeaders
refers to http://werkzeug.pocoo.org/docs/datastructures/#werkzeug.datastructures.EnvironHeaders , where we read
This provides the same interface as the headers and is created from the WSGI environment.
The word Headers ... no, it is not related, but should be related to http://werkzeug.pocoo.org/docs/datastructures/#werkzeug.datastructures.Headers , where we read
Headers are mostly compatible with the Python class wsgiref.headers.Headers
where the phrase wsgiref.headers.Headers
refers to http://docs.python.org/dev/library/wsgiref.html#wsgiref.headers.Headers , where we read
Create header headers for matching-like objects, which should be a header name / value list, as described in PEP 3333
.
The phrase PEP 3333
refers to http://www.python.org/dev/peps/pep-3333/ , where there is no explicit definition of what headings should be, but after searching for the headings of words for a while we find this statement
Therefore, WSGI defines two types of "strings":
"Native" strings (which are always implemented using the type named str) that are used for request/response headers and metadata "Bytestrings" (which are implemented using the `bytes` type in Python 3, and `str` elsewhere), that are used for the bodies of requests and responses (eg POST/PUT input data and HTML page outputs).
This is why in Python 2 you get headers like str
not unicode
.
Now let's move on to decryption.
Neither your .decode('utf-8')
nor mensi .decode('ascii')
(and blindly awaiting any other encoding) is universal, because Theoretically, the values โโof the HTTP header fields can pass anything; the difficult part is getting all parties (senders, recipients and intermediaries) to agree on the encoding. . Having said that, I think that you should act according to the recommendation of Julian Reshka
Thus, a safe way to do this is to adhere to ASCII and select the encoding on top of what is defined in RFC 5987.
after verifying that the user agents (browsers) that you support have implemented it.
The name RFC 5987 is the character set and language encoding for the parameters of the hypertext protocol (HTTP) header field