[Web-SIG] Output header encodings? (was Re: Backup plan: WSGI 1 Addenda and wsgiref update for Py3)

[Ian Bicking]

On Thu, Sep 23, 2010 at 11:17 AM, Ian Bicking <ianb at colorstudy.com> wrote:

>  If these headers accidentally contain non-Latin1 characters, the error
>> isn't detectable until the header reaches the origin server doing the
>> transmission encoding, and it'll likely be a dynamic (and therefore
>> hard-to-debug) error.
>>
>
> I don't see any reason why Location shouldn't be ASCII.  Any header could
> have any character put in it, of course, there's just no valid case where
> Location shouldn't be a URL, and URLs are ASCII.  Cookie can contain
> weirdness, yes.  I would expect any library that abstracts cookies to handle
> this (it's certainly doable)... otherwise, this seems like one among many
> ways a person can do the wrong thing.
>

Minor correction, Set-Cookie, not Cookie.  Good practice is to stick to
ASCII even there (all other techniques have a high risk of mojibake), so
we're really considering legacy integration.  Note that a similar problem is
using [('Content-length', len(body))] -- which also results in a sometimes
confusing error message well away from the application itself.

Generally without validation any data errors occur away from the
application.  A type error is not any different than an encoding error.
Using bytes removes a possible encoding error, but IMHO has a greater chance
of type errors (as bytes are not as natural as text in most cases).
Validation can check all aspects, including encoding (simply by doing a test
encoding).

Consider this hello world:

def app(environ, start_response):
    body = b'Hello World'
    start_response(b'200 OK', [(b'Content-Type',
str(len(body)).encode('ascii'))])
    return [body]

str(len(body)).encode('ascii')?!?  Yuck.  Also no 2to3 fixup can help
there.  bytes(len(body)) does something weird.

-- 
Ian Bicking  |  http://blog.ianbicking.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20100923/0d997a81/attachment.html>