> >> 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 will you do if you want to upgrade a webservice but you cannot > control the client side wich is not utf-8 ? > > On the other hand if your app is sure to receive utf-8 it will not be > difficult to reject everything not utf-8.
That sucks, but you need to draw a line somewhere (and already we are late for drawing the UTF-8/Unicode line). I'd say, if you have legacy clients - you'll leave the server legacy too. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
