Am 01.04.2010, 08:29 Uhr, schrieb Charlie Clark <>:

> I'm not sure if this is a CMF or Zope bug but some views, such as
> folder/view.html do not set the content-type properly which I think  
> causes
> problems for some browsers. If this is a bug, how can I about fixing it?

After some more investigation I think this is a bug in  
zope.pagetemplatefile: content sniffing only takes the <meta> tags for  
content-type into account. Encoding will be set according to portal rules  
but the comnbination can cause problems for some browsers (Firefox, at  
least, ignores the charset and assumes latin-1). Furthermore, the  
behaviour varies between the "classic" rendering and views. As views can  
be configured without a dedicated class I can't see a CMF solution to this.

To test simply add some non-ascii to the "ursa" or "were" main_templates  
and call the @@view.html in Firefox. For some reason CMFDefault's  
@@view.html still renders correctly. I guess this must be related to the  
__init__ in ursa globals. This probably needs patching so the behaviour is  
the same. At least we've got tests for this.

I don't think depending on the meta declaration is the right approach.  
I've seen it used incorrectly very often and it's supposed to be a hint  
for the browser but will be overridden by the content-type in the header.  
Better to add proper detection for the HTML Doctype in  
zope.pagetemplate.pagetemplatefile. I'm not sure about the charset - I  
think there's a way to check for the character encoding "manually" using  
the BOM and this should be used with the meta declaration as a fall-back  
and there should be an error if there is a mismatch. Should I submit a bug  
on this?

Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to