System message:
--
status: chatting - deferred
__
Repoze Bugs b...@bugs.repoze.org
http://bugs.repoze.org/issue100
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
Tres Seaver tsea...@agendaless.com added the comment:
The only correct way to decode values in the payload of an HTTP POST request
is to use the charset supplied in the Content-Type header of that request, or
fall back to ISO-8859-1.
RFC 2616, section 3.7.1, says:
When no explicit charset
Yuen Ho Wong wyue...@gmail.com added the comment:
I'm not entirely sure why this is not actionable on any realistic level, and
what you mean by
lower layers. Perhaps you can explain further or point me to a previous
discussion if this has been
talked about before?
--
status:
Chris McDonough chr...@plope.com added the comment:
I mean that I personally don't know how to change the software based on your
suggestions so
far in a way that adds significant value, and that if WSGI2 will handle the
encoding and
decoding issues, maybe this should just do something better
Chris McDonough chr...@plope.com added the comment:
I believe this.
On the other hand, I'm not sure that a 'charset' setting dedicated to
repoze.who or to
repoze.what is really sufficient. Who will set the charset? What will it be
set to? What does it
mean to individual plugins? What
Yuen Ho Wong wyue...@gmail.com added the comment:
Well I think the WSGI 1.x spec has made a mistake of mandating all strings in
environ to be
byte strings while not defining a global environment variable to give
middlewares a hint of how
to decode the byte strings. This is a recognized
New submission from Yuen Ho Wong wyue...@gmail.com:
It seems that from the design to the implementation of repoze.who and
repoze.what, including
its plugins, have completely failed to support holistically any charset other
then Latin-1. As of
now, there is not an option global to repoze.who,
