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
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
Yuen Ho Wong wyue...@gmail.com added the comment:
Ok I agree it's not important to try to emulate mod_auth_tkt, which I think is
a totally dead
project anyway. But I have to take issue with the way unicode decoding is dealt
with in this
plugin.
First of all, you are not even suppose
Yuen Ho Wong wyue...@gmail.com added the comment:
Yes the charset is irrelevant here. Decoding shouldn't be done here anyway. I
think I have to
reiterate the problem as accepting unicode strings because it breaks
conformance with the
WSGI spec. There never should have been unicode strings
Yuen Ho Wong wyue...@gmail.com added the comment:
P.S. I think this solution solves the uncertainty of possibly clashing with the
mod_auth_tkt use of
the userdata field, however small this (non) issue maybe?
__
Repoze Bugs b...@bugs.repoze.org
http
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
New submission from Yuen Ho Wong wyue...@gmail.com:
This is a minor bug remotely related to issue 100.
According to the WSGI spec, all the strings in the environ should be byte
strings. However, if
some IIdentifier plugin returns an unicode login name for identity dict,
AuthTktCookie
