2009/8/7 gert <[email protected]>: > > > > On Aug 6, 8:44 pm, Damjan <[email protected]> wrote: >> > Not very well. >> >> > We are having another argument about WSGI specification and Python 3.0 >> > at the moment on Python WEB-SIG list. The discussion seems to have >> > exploded over night and have about 30 messages to read about it yet. >> >> > If some sort of resolution isn't reached this time I am going to give >> > up and simply not support Python 3.0. >> >> I'd say that requiring UTF-8 (on the client side) and making most of >> WSGI unicode is the better option. Maybe, as P.J.E says, that way WSGI >> will loose some of it's idempotency with HTTP, but who cares... WSGI >> is about Python applications! >> >> And if a request comes that can't be decoded as UTF-8 .. then a "400 >> Bad Request" error should be thrown. >> >> The other option, will mean that every web framework and every WSGI >> middleware, and every programmer will have to reimplement the >> character conversion heuristics (and probably do it wrong). >> >> I don't see any problems with declaring an UTF-8 constraing for data >> coming from the HTTP side. Less (unneeded) choice for programmers, >> middleware and frameworks is good! > > What about returning binary data to a browser (png image) ? I thought > this can only be done in latin-1 ?
Totally unrelated. The discussion is only about values in WSGI environment and not how data is returned, which would still have to be bytes for response content. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
