Ian Bicking wrote:
I propose we switch primarily to "native" strings: str on both Python 2 and
3.
Fine.
wsgi.input remains byte-oriented, as does the response app_iter.
Good.
These both form the original path. It is not URL decoded, so it should be
ASCII.
Great! BUT.
Undecoded script_name/path_info *cannot* be provided by some gateways:
primarily, but not only, CGI.
Such a gateway can reconstruct what it thinks the undecoded versions
should have been, but this is not reliably accurate. I would like a way
(eg. a flag) for the gateway or server to specify to the application
that script_name/path_info are potentially inaccurate. Then the
application can react by avoiding IRI (and %2F, though arguably that
should be avoided anyway).
This sends different text, but is highly preferable.
Yes. All schemes to send non-ASCII in cookies require sending different
text; URL-encoding is a common choice of ad-hoc wrapping. I don't think
WSGI has to worry too much about explaining this, it's a known hazard of
the web in general. It doesn't work in any other environment, so nobody
should be expecting it to work in WSGI.
What happens if you give unicode text in the response headers that cannot be
encoded as Latin1?
UnicodeEncodeError.
Should some things be unicode on Python 2?
Don't think so.
--
And Clover
mailto:a...@doxdesk.com
http://www.doxdesk.com/
--
And Clover
mailto:a...@doxdesk.com
http://www.doxdesk.com/
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
