[issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr

Nick Coghlan added the comment: We don't have anyone clamouring for this, and the third party module https://ftfy.readthedocs.io/en/latest/ has a lot more utilities for working with messy binary inputs and incorrectly decoded text than we'd ever add to the standard library, so I'm going to r

[issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr

Nick Coghlan added the comment: Reviewing the items I had flagged as dependencies of issue 22555 for personal tracking purposes, I suggest we defer further consideration of this idea to 3.6 and/or the creation of a WSGI 2.0 specification. -- versions: +Python 3.6 -Python 3.5 _

[issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr

Robert Collins added the comment: So I guess the API concern I have is that there are two cases: - common spec compliant - US-ASCII + RFC2047 - dealing with exceptions - UTF8 or otherwise The former totally makes sense as a codec, though the current email implementation of it isn't quite a co

[issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr

Nick Coghlan added the comment: I'm not wedded to the specific algorithm - I definitely don't consider myself an HTTP or WSGI expert. I do like the general idea of treating "wsgistr" as a serialisation format though, as that's effectively what it is at this point. --

[issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr

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

[issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr

Nick Coghlan added the comment: Updated issue title to reflect current proposal -- title: Add wsgiref.util helpers for dealing with "WSGI strings" -> Add wsgiref.util.dump_wsgistr & load_wsgistr ___ Python tracker