[issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr

2018-06-09 Thread Nick Coghlan


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 reject this as only being theoretically 
useful, and not actually solving a practical problem for users.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr

2015-05-11 Thread Nick Coghlan

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr

2014-09-25 Thread Robert Collins

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 codec.

The latter almost wants to be a separate API, which I may propose as part of 
WSGI for HTTP/2; nevertheless in PEP- its integral to the main API because 
of the bytes-encoded-as-codepoints-00-ff solution.

So, perhaps:
 - a codec or something looking like it that covers the common case
   this would not permit specifying codecs on decode, for instance [since 
RFC2047 is self describing].
 - documentation for the uncommon case. *Possibly* a helper function.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr

2014-09-25 Thread Nick Coghlan

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr

2014-09-25 Thread Robert Collins

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr

2014-09-23 Thread Nick Coghlan

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com