[Web-SIG] Request for Comments on upcoming WSGI Changes
and-py at doxdesk.com
Tue Sep 22 17:19:51 CEST 2009
Alan Kennedy wrote:
> Why can't we just do the same as the java servlet spec?
Because Servlet is a walking, stinking demonstration of how *not* to
Every servlet container has its own different method of selecting input
character sets, and the default encoding is almost never right. Most
deployed JSP applications out there are using the wrong charset and do
the wrong thing with any non-ASCII character. This is not something to
Pushing the choice of encodings out to a 'deployment issue' where the
application doesn't get to decide is a Wrong Thing. I hate dealing with
this nonsense in Java and I do not want the same approach to become
common in Python.
> I see this as being the same as Graham's suggested approach of a
> per-server configurable charset
This is absolutely the opposite of what I want as an application author.
I want to hand out my WSGI application that uses UTF-8 and know that
wherever it is deployed the non-ASCII characters will go through without
The application (perhaps via a framework it is using) is the party that
is in the best place to know what character encoding it wants to deal
with. Give the application a consistent way to handle that encoding
itself, because the poor sod deploying it isn't going to know any better.
> Those frameworks obviously have solved all of the problems of decoding
> incoming request components from miscellaneous unknown character sets
> into unicode, with out any mistakes
Er, no. That's the point. It cannot currently be done in all deployment
environments. When they're not running via their own built-in servers,
the frameworks have to do the same as the rest of us: guess.
That guess may not be as troublesome as it is in Java (mainly because
for us it doesn't affect QUERY_STRING parameters), but it's still not
reliable, which is why today you can't have a WSGI application with
pretty non-ASCII URLs that will deploy consistently. I want this fixed.
mailto:and at doxdesk.com
More information about the Web-SIG