TG 1.5 Beta with CherryPy 3.2 RC1 stumbling points...

4 views
Skip to first unread message

Sam

unread,
Jan 7, 2011, 4:40:02 AM1/7/11
to TurboGears
Since, as covered in my other thread, CherryPy 3.1.2 is not working
for me, I thought I'd try the Release Candidate for CherryPy 3.2.

First stumbling point is the ContentType is now set in the headers as
follows:
Content-Type: text/html;charset=ISO-8859-1

It used to be set as:
Content-Type: text/html; charset=utf-8

which is what it needs to be. Otherwise all my   characters show
up as weird As.

What's the best way to fix this?

Thanks!

Daniel Fetchinson

unread,
Jan 7, 2011, 8:09:00 AM1/7/11
to turbo...@googlegroups.com

What makes you think   will be rendered differently if the
charset is changed? I'd think in both cases it will show up as a
non-breaking space.

Cheers,
Daniel


--
Psss, psss, put it down! - http://www.cafepress.com/putitdown

Sam

unread,
Jan 7, 2011, 4:47:30 PM1/7/11
to TurboGears
Daniel

Right now it's being rendered by the browsers as "Â" (without quotes).

That's because it's telling the browser the wrong encoding.

The best reference I can find is:
http://stackoverflow.com/questions/1461907/html-encoding-issues-a-character-showing-up-instead-of-nbsp

So how do I tell CherryPy to tell the browser that it's utf-8?

Thanks
Sam

On Jan 7, 5:09 am, Daniel Fetchinson <fetchin...@googlemail.com>
wrote:

Daniel Fetchinson

unread,
Jan 7, 2011, 7:28:36 PM1/7/11
to turbo...@googlegroups.com
> Right now it's being rendered by the browsers as "Â" (without quotes).
>
> That's because it's telling the browser the wrong encoding.
>
> The best reference I can find is:
> http://stackoverflow.com/questions/1461907/html-encoding-issues-a-character-showing-up-instead-of-nbsp
>
> So how do I tell CherryPy to tell the browser that it's utf-8?

Is this what you are looking for?
http://www.cherrypy.org/wiki/BuiltinTools#tools.encode

Cheers,
Daniel

>> What makes you think &nbsp; will be rendered differently if the
>> charset is changed? I'd think in both cases it will show up as a
>> non-breaking space.
>>
>> Cheers,
>> Daniel
>>
>> --
>> Psss, psss, put it down! -http://www.cafepress.com/putitdown
>

> --
> You received this message because you are subscribed to the Google Groups
> "TurboGears" group.
> To post to this group, send email to turbo...@googlegroups.com.
> To unsubscribe from this group, send email to
> turbogears+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/turbogears?hl=en.

Sam

unread,
Jan 8, 2011, 12:21:31 AM1/8/11
to TurboGears
Yes!

I added

tools.encode.encoding = "utf-8"

to the global section of my app.cfg and success!

I haven't seen any of those dreaded 408 errors yet. CherryPy 3.2
seems to work nicely now. I'll inform anyone if I find any other
issues.

Thanks
-Sam

On Jan 7, 4:28 pm, Daniel Fetchinson <fetchin...@googlemail.com>
wrote:
> > Right now it's being rendered by the browsers as "Â" (without quotes).
>
> > That's because it's telling the browser the wrong encoding.
>
> > The best reference I can find is:
> >http://stackoverflow.com/questions/1461907/html-encoding-issues-a-cha...
>
> > So how do I tell CherryPy to tell the browser that it's utf-8?
>
> Is this what you are looking for?http://www.cherrypy.org/wiki/BuiltinTools#tools.encode

Christoph Zwerschke

unread,
Jan 8, 2011, 8:25:45 AM1/8/11
to turbo...@googlegroups.com
Am 08.01.2011 06:21 schrieb Sam:
> I haven't seen any of those dreaded 408 errors yet. CherryPy 3.2
> seems to work nicely now. I'll inform anyone if I find any other
> issues.

Thanks. Please add them to the newly created
http://trac.turbogears.org/ticket/2539
so we won't forget to address these for the TG 1.5 final release.

-- Christoph

Christoph Zwerschke

unread,
Jan 11, 2011, 6:20:03 AM1/11/11
to TurboGears
On 8 Jan., 06:21, Sam <samsli...@gmail.com> wrote:
> I added
> tools.encode.encoding = "utf-8"
> to the global section of my app.cfg and success!

As far as I understand, the problem seems to be that CP 3.2 has
tools.encode on by default, and tries to encode to the first accepted
charset. This is often iso-8859-1 instead of utf-8, but TG returns the
response already encoded as utf-8, not as unicode, so this does not
work and the utf-8 output will be declared as iso-8859-1 which renders
garbage.

So I think the better and more performant solution is to completely
switch off the encode tool because it's not needed. Can you check how
that works for you? I.e. instead of tools.encode.encoding = "utf-8"
set:

tools.encode.on = False

-- Christoph

Sam

unread,
Jan 11, 2011, 6:16:49 PM1/11/11
to TurboGears
On Jan 11, 3:20 am, Christoph Zwerschke <c...@online.de> wrote:
> So I think the better and more performant solution is to completely
> switch off the encode tool because it's not needed. Can you check how
> that works for you? I.e. instead of tools.encode.encoding = "utf-8"
> set:
>
> tools.encode.on = False

That works fine!

Thanks

Christoph Zwerschke

unread,
Jan 12, 2011, 3:34:44 AM1/12/11
to turbo...@googlegroups.com
Am 12.01.2011 00:16 schrieb Sam:
>> tools.encode.on = False
>
> That works fine!

Ok, after setting this as default now in TG 1.5 and making some more
small changes, the test suite reports no errors with CherryPy 3.2.

Will probably make a TG 1.5b2 release this weekend, if you find any
other issues to be fixed, let me now.

-- Christoph

Reply all
Reply to author
Forward
0 new messages