On Thu, Sep 23, 2010 at 11:17 AM, Ian Bicking <i...@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
_______________________________________________
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
