Robert Collins added the comment: So this looks like its going to instantly create bugs in programs that use it. HTTP/1.1 headers are one of: latin1 MIME encoded (RFC2047) invalid and working only by accident
HTTP/2 doesn't change this. An API that encourages folk to encode into utf8 and then put that in their headers is problematic. Consider: def dump_wsgistr(data, encoding, errors='strict'): data.encode(encoding, errors).decode('iso-8859-1') This takes a string that one wants to put into a header value, encodes it with a *user specified encoding*, then decodes that into iso-8859-1 [at which point it can be encoded back to octets by the wsgi server before putting on the wire]. But this is fundamentally wrong in the common case: either 'data' is itself suitable as a header value (e.g. it is ASCII - recommended per RFC7230 section 3.2.4) or 'data' needs encoding via RFC 2047 encoding not via utf8. There are a few special cases where folk have incorrectly shoved utf8 into header values and we need to make it possible for folk working within WSGI to do that - which is why the API is the way it is - but we shouldn't make it *easier* for them to do the wrong thing. I'd support an API that DTRT here by taking a string, tries US_ASCII, with fallback to MIME encoded with utf8 as the encoding parameter. ---------- nosy: +rbcollins _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22264> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com