Code review comment for lp:~gz/pyjuju/os_token_string_type_1030897

On 2012/10/01 17:20:44, gz wrote:
> On 2012/10/01 14:42:48, hazmat wrote:
> >
> > pls explictly encode utf8. str('some unicode char') is environment
dependent.

> So, this is the messy detail I was trying to avoid, but a summary:

> Behaviour of str()
> ==================

> Assuming a unicode object (otherwise __str__ is called), this is
basically
> equivalent to:

> obj.encode(sys.getdefaultencoding())

> This is not locale dependent, and in modern Pythons the knob for
changing the
> default encoding is hard to access, in the context of the juju client
we are
> basically assured equivalence to:

> obj.encode('ascii')

It may be hard, but people still do it, and its global for the
interpreter. Its sadly common for py2 web apps to make this utf8 via
sitecustomize. If we want ascii and we know, it we should just be
explicit about it then relying on implicit conversion.

> Which we could do instead, as the str() spelling is generally a bit of
a red
> flag as people like using it to try papering over actual encoding
problems.

yup. sounds good.

> HTTP header encoding
> ====================

> Header field content is specified in HTTP 1.1 as being either
ISO-8859-1 or
> encoded as per MIME headers:

> <http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2>
> <http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2>
> <http://www.ietf.org/rfc/rfc2047.txt>

> This is not a very common or easy to use encoding scheme, and in
practice, no
> one really does it. The in progress revision of the specification is
changing
> the requirements around this:

> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/74>

> So, keystone should never give a non-ascii token but for documentation
purposes
> encoding as utf-8 is confusing given that's not the correct scheme in
this
> context.

fair enough.

https://codereview.appspot.com/6573068/